DBus reconnect support (initial attempt)

[Colin Walters]

On Mon, 2005-03-14 at 17:14 -0800, Tomislav Vujec wrote:
> On Mon, 14 Mar 2005 18:22:26 -0500, Colin Walters wrote:
> > The system bus will be restarted on reboot, however often that happens.
> > For my personal system that's several times a day, as apm and acpi are
> > broken on my laptop.
> 
> I think that the fact that acpi is broken on your laptop should be
> considered a bug. 

Umm...I'd be the first to agree with you.

> I was in a same situation a couple of months ago, but
> ever since I managed to reliably suspend, my uptime holds time
> difference since the last kernel upgrade. 

If you run a desktop system, you should include X and gdm in there.
Neither are restarted automatically for security updates.  I'm sure
there are others too that I'm not thinking of.

I would argue that there is really no fundamental difference between
restarting X and restarting the system.  Sure, you have the output of
'uptime', but what you *really* care about is how long it takes you to
get back into the desktop session and do work.  If we can make the
system bootup fast enough (and Windows XP and MacOS X show it's
possible), then restarting the whole system isn't a big deal.

> No matter how optimized the
> startup procedure really is, it will never be the same as keeping the
> status of all running applications, which always requires manual
> interaction.

Not necessarily.  We could have a way for the system to ask the user
sessions "do you have any unsaved data".  If they don't, and it's
between 3am and 5am, and the user hasn't touched the computer in 3
hours, we simply reboot.  Note that if apps are written correctly and
preserve state otherwise (what documents were open, what web pages were
being visited, what IM conversations were active, etc), then to the user
there isn't a big difference.

> Therefore reboot is evil, and it should be avoided at all costs. Now since
> the dbus serves as a very low service, it might require restart of all
> dependent applications, which in turn could be very similar to reboot.

To me there are two major cases here:

1) Desktop - Here to the user, logging out the desktop == reboot.  
   If as an implementation detail we make "rebooting" really just
   restarting some dependency chain which includes X, then what we're
   really doing is making "rebooting" faster.
2) Server - If you're running e.g. a production webserver with Apache,
   then yes, not rebooting is important.  But it's not like we're going
   to just put 'reboot' into the %post of the dbus package.  Instead,
   the smart way to do it is to notify the system administrator that
   an installed upgrade requires a reboot to take effect.  At that point
   they have a decision to make.  Let's say that the dbus upgrade is for
   a security errata.  In that case they evaluate whether dbus is
   exposed to any threats and whether they can ignore the upgrade for
   now.  If they have no hostile local users, it's probably reasonable
   to just not reboot.  Just like for a lot of the kernel flaws that
   have been exposed recently.

> I'll admit here that I am not deeply familiar with the dbus interface, but
> why shouldn't be possible to reliably wait for d-bus to start again? 

In theory, it is possible.  Just like in theory, you could take the code
from a new kernel update and attempt to overlay it into the running
kernel, by writing custom upgrade code.

My point is that no one is going to make it work reliably.  Our current
usage of D-BUS is small relative to our plans for it; for example, I'd
like it if the packaging system could notify the sessions when a new
package is installed (so you can tell the user "An update was installed
which requires a reboot", if they installed a new kernel or dbus
package).  There's also some plans to base a new "init" system on it.  
All of this becomes significantly more difficult if the bus can randomly
go away.

> You
> mentioned reliable locking, but my hope would be that the apps can choose
> between the full restart requirement, and the some kind of graceful
> handling of the situation. Now the way I see it, a lot of apps could be
> able to do the graceful handling of the d-bus restart, and therefore it
> pays of if their status is kept and the user is not forced to restart.

The problem is it has to work 100% reliably, for every application, or
you have lost any benefit from all of the work.  As soon as e.g. some
app locks up and the user is unable to save their data (this actually
happened to me when I upgraded dbus in Fedora, which screwed HAL, which
then screwed gnome-vfs, which in turn screwed gedit), then we lose.
Far, far better to require a reboot at the user's convenience for just a
few packages and ensure we reliably preserve their data and running
applications until they choose to reboot.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050315/a661e72c/attachment.pgp