dbus upgrade issue
hp at redhat.com
Fri Dec 15 17:07:57 PST 2006
Ray Strode wrote:
> It turns out that the session dbus-daemon is calling exit() after
> reloading its config following a hangup signal that's generated during
> the upgrade (because of an selinux policy update). The session daemon
> is calling exit(1) because a new, incompatible session.conf is getting
> installed to /etc/dbus-1. The new session.conf adds a
> <standard_session_servicedirs /> tag that the old, running session
> daemon doesn't understand.
Hmm, the exit() seems plain wrong; better behavior would be to just
ignore the new config file. So step 1 is to just be sure we patch this bug.
However - are you sure this is due to HUP? I thought the daemon had a
watch on the config directory.
If it is due to HUP, I believe I complained at one point about a
"killall -HUP dbus-daemon" in the init script that should have only
killed the particular pid... whether or not that's the source of the
problem, in general I'm not sure HUP'ing the *session* buses on upgrade
is appropriate. I think it would be fine for the session bus config to
be loaded only at login time and never again, or maybe only on explicit
HUP by the user.
> To get around this we need to keep the running dbus-daemon happy, and
> still give the updated config file to the new version of the
> dbus-daemon when the user logs out and logs in. The easiest way I can
> come up with to do that is to move the config file to a new location,
> and keep a backward compatible config file in the old place.
Assuming we aren't moving the config file anyway (let's keep the /etc
vs. datadir issue separate from this issue), this seems like an
overreaction to me. Surely there's a less disruptive solution.
Have you thought about the upgrade scenarios if you do this? For
example, if there are new security policies required for HAL to work,
and you have moved the security policy files to /usr/share, the running
system daemon will never see the new policies. HAL will thus not work
until the system is rebooted. Or worse, the running bus could see that
all its policies have vanished and adopt the default 100% locked down
policy, which would basically hose everything.
Remember also that RPM either can't replace a directory with a symlink
or vice versa, I don't remember which, in any case it seems a bit scary.
> This brings up an interesting observation though. session.conf and
> system.conf aren't really config files at all. They even say
> something like "don't ever edit this file, use session-local.conf
> instead" or something. In fact, the options in there seem more
> distribution specific than system specific. So given that 1) the user
> shouldn't change the settings 2) the user wouldn't even normally want
> to change the settings, why are we installing the files in /etc ?
There may be cases where editing the file is required; for example, I
don't think we allow removing a listen address in the -local.conf, there
may be other things that are impossible to override in -local.conf.
AFAIK the conf file has not been audited or designed in such a way that
the .d/-local are always enough.
You are correct that the config files mix mostly "factory" configuration
with maybe one or two things a local site might change, but I'm not sure
the split is cleanly between the main file and the -local.
I believe a number of things in /etc are like this; dbus did not invent
the -local/.d approach.... you'd have to ask an FHS geek what the
Official Word is.
> For FC-6 I'm moving the files to /usr/share/dbus-1 and stripping the
> write permissions off of them. This seems more correct and will help
> fix our bad upgrade issue. I've attached the patch that I'm using to
> do that.
Doing this in a Fedora-specific patch I consider a bad idea, fwiw. There
is nothing Fedora-specific about the /etc vs. /usr/share issue, and
these file locations are something of an application interface.
> One thing I'm not moving for FC-6 is the /etc/dbus-1/system.d
> directory because a lot of packages depend on it being there. It
> might make sense to move it, though, and create a compatibility
I think you'd find this creates a world of pain (and cross-distribution
incompatibility) if done only in Fedora. Even if done globally, it will
be a nasty migration period just due to apps trying to run on both old
and new distributions.
I'd recommend separating the two issues (upgrade crash and file
locations) for discussion and thinking purposes, and be sure we have
independent ideas of the right fix for each. If it so happens that we
should do /usr/share anyway then it will fortuitously fix the Fedora
upgrade problem too.
More information about the dbus