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.
Attachment:
signature.asc
Description: This is a digitally signed message part