The process then tries to /bin/dbus-launch, which then fails with:

/bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed.

Relationship between gconf and dbus? I have tried to delete the ~/.dbus and set permissions 755.

Please advise :)

(In reply to Michael Couck from comment #0)
> GConf Error: Failed to contact configuration server; some possible causes
> are that you need to enable TCP/IP networking for ORBit, or you have stale
> NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for
> information. (Details -  1: Not running within active session)

GConf is deprecated and its use is not recommended. However, if you're running a large stack of Java and something in there depends on it, you're probably stuck with it.

> Relationship between gconf and dbus?

Old GConf versions used ORBit (CORBA) as an inter-process communication transport, as described in the error message you quoted. Recent-ish GConf versions use D-Bus instead of ORBit, and I think there might even have been some intermediate versions that used D-Bus for single-instance management and ORBit for the "real work".

Depending which version of GConf this is, it might be using D-Bus but have a misleading error message that still talks about ORBit, or it might still be using ORBit for some or all of its functionality. If it does not in fact use D-Bus, you will have to find someone else to help you with that.

(In reply to Michael Couck from comment #1)
> The process then tries to /bin/dbus-launch, which then fails with:
> 
> /bin/dbus-launch terminated abnormally with the following error: Autolaunch
> error: X11 initialization failed.

"dbus-launch --autolaunch" is the mechanism for automatically starting a D-Bus "session bus" to accompany your X11 display. If you don't have an X11 display (which you probably don't on a Jenkins server), there's your problem: autolaunching won't help you. Similarly, if DISPLAY is pointing to an inaccessible, stopped or otherwise unusable X11 server, autolaunching can't work.

You can have a D-Bus session bus without an X11 GUI session; but it will not be started automatically (you have to start it yourself), and will not be stopped automatically (you're responsible for stopping it when the session is over, for whatever definition of "session" you want to use).

In recent D-Bus versions (>= 1.8) the recommended way to have a short-lived session bus for regression tests etc. is:

    dbus-run-session -- make check

replacing "make check" with whatever test you wanted to run. This will run a dbus-daemon; run "make check" with appropriate environment variables to use that dbus-daemon (the most important one is DBUS_SESSION_BUS_ADDRESS); wait for it to exit; kill the dbus-daemon; and exit with the same status that "make check" reported.

In older D-Bus versions, pick one of these:

* run your tests with DISPLAY pointing to a "headless" X server like Xvfb, which will make autolaunch work, like it does on normal GUI systems;

* get the dbus-run-session.c source code from a newer version and modify it to compile standalone (you'd probably only need to delete a couple of #includes and use setenv() instead of dbus_setenv());

* use <http://cgit.freedesktop.org/telepathy/telepathy-glib/tree/tools/with-session-bus.sh?h=telepathy-glib-0.22>, which is basically dbus-run-session as a shell script;

* manage a dbus-daemon yourself, using dbus-run-session or with-session-bus.sh for reference.

It sounds as though this is a support request caused by misconfiguration/misuse rather than a D-Bus bug, but leaving this open with NEEDINFO for now.

If you believe you have found a D-Bus bug, please give enough information that a developer could reduce it to something reproducible: operating system and its version, D-Bus version, GConf version if you think it's relevant, steps to reproduce the bug, that sort of thing. At the moment I don't know enough about your system or the context for this issue to offer anything beyond guesses.

(In reply to Michael Couck from comment #0)
> The machine is rendered useless unfortunately, next step is to reinstall
> everything, long process.

I have no idea why failure of either GConf, dbus-daemon or a unit test would damage a system badly enough to require a reinstall.

Thanks for the detailed description Simon. 

There is a GUI strangely enough, just for emmergencies. The server is public facing incidentally, and I would be happy to give access to whoever needs it to have a quick look. Not public obviously, my address is michael.couck@gmail.com.

I really couldn't say if it is a bug, an inconsistency, a file that cannot be read etc. But I have been running this server for several years without incident, and the only thing that has changed is that the job that is failing is now using the Apache Tika project for parsing files.

I have tried to execute the job in headless mode without success.

So if someone would like a quick look just gove me a buzz and I'll provide the login details.

Simon, I tried the same job on another server, this time a 32 core Dell R910, from a shell, executing the maven build job, with the same results. So something in Apache Tika seems to try to invoke dbus and X11 server. OS details:

LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 6.6 (Final)
Release:        6.6
Codename:       Final

Linux localhost.localdomain 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Very strange.

(In reply to Michael Couck from comment #3)
> There is a GUI strangely enough, just for emmergencies.

Whether a GUI *exists* is not directly relevant to whether autolaunch works. The conditions for autolaunch to work are: if the task under test started an X11 GUI app, e.g. xterm, would that work? (In other words, it must have the DISPLAY environment variable set, and be able to access the X server that the variable points to, which might require XAUTHORITY or a matching user ID or whatever.)

> I really couldn't say if it is a bug, an inconsistency, a file that cannot
> be read etc.

Sorry, if you do not have some sort of evidence of a bug in D-Bus (as opposed to a bug or misconfiguration tangentially related to D-Bus) then I am not going to spend D-Bus maintenance time investigating this. There's a limit to the amount of time I can spend on this stuff, and I'd rather use it to fix bugs within D-Bus itself that can affect many D-Bus users. To put it another way, I am not your IT department :-)

> the only thing that has changed is that the job that is
> failing is now using the Apache Tika project for parsing files

That would be a good place to start looking, then. Looking at https://tika.apache.org/1.7/formats.html I wouldn't be surprised if something in that stack expects to be run within the context of an X11 GUI session (i.e. with the right uid and environment variables to talk to X11).

Thanks Simon, you are probably right, this is not a dbus issue, nor gconf or even x11. I think this lies with Apache Tika, now that two servers fail with the same error. Thanks for the time. 

There is no IT department, just me I am afraid ;)