fail to start X, unknown tag standard_session_servicedirs

[Havoc Pennington]

Steev Klimaszewski wrote:
> 
> I filed a bug about a similar situation to this - when working on the 
> FreeBSD backend, we were having issues with some people where D-Bus 
> would simply segfault or say that it was out of memory and we couldn't 
> figure out why.  It turned out to be either blank configs, or an added 
> config that wasn't formed right.  It was decided to not be a bug.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=8361
> 
> You can read the comments why in that bug.


If it segfaults, that certainly is a bug. If #8361 mentions segfaulting 
though, I missed it.

#8361 is a bit different from whether to ignore unknown xml nodes. The 
reason is that #8361 is about a completely *empty* config file. The 
thing is, dbus-daemon does not have any sensible default behaviors. It 
doesn't even know if it's a session or system bus, or neither, and 
there's no rational way to pick the appropriate defaults.

The session and system bus *do* have sensible default behaviors, but 
they aren't hardcoded in the binary anywhere, they are just shipped in 
the two respective config files.

The dbus config file isn't like the one for most programs, in that there 
are few if any reasons to modify it. dbus-daemon is not something that 
needs "setting up" for each local installation or environment. It works 
out of the box and if you just don't touch it then it's fine. (Except 
for bugs of course.)

The purpose of the config file instead is to specialize dbus-daemon by 
defining a particular bus type, whether system bus, session bus, or the 
recently-proposed "external" bus.

So what I would say is that a problem with the config file will 99% of 
the time be a distribution packaging problem, or even dbus upstream 
problem, not a site local problem. To me this is a strong argument for 
the dbus-daemon binary being relatively loud about the issue and forcing 
it to get fixed.

We could hardcode the dbus-daemon binary to contain the same information 
that's in the default .conf files that we ship, but to me that's just 
putting the same info in two places which is a) bloat and b) a good way 
to have weird bugs.

Again though, if it either segfaults or fails to print a nice error 
somewhere you can find it, I would say it's a bug.

Regarding ignoring unknown XML elements, I don't think it can even 
happen unless a) you mistakenly type in garbage that won't work, in 
which case an error message is helpful or b) your installation is just 
screwed, as Frederic's was - he was running mismatched config file and 
daemon due to having two daemons installed incorrectly so they were not 
using their corresponding config files.

If the problem had been silently ignored, then the bus would not have 
been able to find any services, which (at least once a desktop heavily 
uses dbus) would result in a completely broken desktop. If X ignores 
unknown config options, it can probably manage to start up and work 
anyhow, perhaps just choosing a lame screen resolution. In the end X 
shouldn't even _have_ a config file if at all possible since it can 
instead autoprobe the info.

For dbus-daemon, we aren't adapting to a local install or machine, so 
there's no issue of required configuration; the configuration is 
virtually always just set in the factory so to speak.

The config options set in the factory are almost all essential to the 
bus working at all, so continuing doesn't make a lot of sense to me; 
better to bail out and let someone fix an obvious problem, than have the 
desktop try to start up then implode in bizarre ways.

The dbus config can easily be security-sensitive, too, so proceeding 
with a config file / daemon binary mismatch sounds dangerous to me.

Havoc