fail to start X, unknown tag standard_session_servicedirs
hp at redhat.com
Sat Nov 25 22:10:57 PST 2006
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.
> 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.
More information about the dbus