Schedule for Monday's FESCo Meeting (2012-06-18)

Richard Hughes hughsient at
Sun Jun 17 20:57:08 UTC 2012

On 17 June 2012 18:49, Richard W.M. Jones <rjones at> wrote:
> You're asserting that dbus-daemon etc cannot be restarted, but without
> saying why.

Okay, I'll say why. The core protocol was never designed to support
the dbus-daemon being restarted.

>  The current design may make restarting some daemons
> difficult but we should fix those problems.

So, to install a zlib update, according to your proposal we now have
to QA the effects of restarting several per-system userspace daemons
at runtime (which may be disabled or enabled depending on the specific
user config) and also have to test the session clients (of all three
desktops) code support when core system services disappear and then
(hopefully) reappear a few seconds later. And make sure that this
works for multi-user logins and fast-user switching. And we hope that
the updates have not failed to be installed leaving the session
without core stuff like gnome-session and dbus. So then we try to roll
back to the previous system state using snapshotting, even though the
non-idle system has already written other normal stuff to /usr and
/etc which we mistakenly revert... See how crazy this sounds?

Please trust me when I say we've thought about this stuff quite a lot,
and the only sane way to do this was wither with a recovery partition
or a minimal boot environment like I've suggested. It's a miracle the
stuff we try to QA now works at all.

>  - QNX
>  - z/VM
>  - EROS

Have you got an example of any popular desktop OS?

> It might not be possible *with poorly designed Linux
> daemons* but that's quite a different thing.

As the maintainer of a few of the aforementioned "poorly designed
Linux daemons" I can tell you that's simply not possible. I'm sure you
appreciate how complicated restarting a service without dropping state
would be with your work with libvirtd.


More information about the devel mailing list