On Wed, 2005-07-06 at 13:24 +0200, Sjoerd Simons wrote: > On system bus restart debian/ubuntu also stop and start the daemons that use > dbus (like hal). So for them it's not really a problem. How can one possibly know the list of all applications that use D-BUS running on the system? What about other 3rd party applications? > For applications using > services, like gvm it's somewhat more problematic, but not impossible. It is really hard. Doing it truly correctly (i.e. not having occasional/rare and subtle race conditions all over) would consume a large amount of developer time. That developer time would be much better spent on end-user visible features. Let me give one example of a problem from the patch Martin posted. I hadn't looked at the gnome-volume-manager code before now, but it appears the way it works in a majority of cases is like this: 1. receive HAL message 2. internal processing 3. invoke HAL method 4. wait for reply 5. invoke more HAL messages, wait for reply, etc. 6. more processing (mounting, etc) If at any of steps 2,3,4,5 HAL or D-BUS goes away, what will happen is that the method invocation will time out, and the "more processing" step won't happen. The way this will occur in the real world is that a user gets notified by the system that security updates are available that they should apply. The click on the icon, and it says it's processing in the background. On Ubuntu this runs dpkg, which at some point restarts dbus and hal (closely spaced if you're lucky, widely if you're not). While this update is happening, the user decides to listen to some music. They plug in their iPod. Unfortunately for them, they plug it in right as the update and restart of dbus and HAL is happening. The HAL message gets lost (or is even not sent because HAL wasn't running to get the hotplug event), and nothing happens on the user's desktop. Maybe if they unplug it and plug it back in it works, maybe not. They get the impression of an unreliable/buggy desktop. Again, the alternative is simple: just notify the user that one of the installed packages requires a restart to take effect. Now, I would say that it's your choice what experience your users get, but this is also relevant from an ISV point of view. People writing D-BUS applications should know that they can rely on the bus and certain critical services being present, and shouldn't be spending their time trying to handle their communications framework being restarted. > The > biggest problem we had with it that when it reconnected, hal was initialising > and so all the devices showed up as new, causing actions to be run again. > > Applications should handle the case that the services they use restart or even > disconnect in some way in a somewhat sane manner. That's easy to say. It's a lot harder for the application writers to actually do. It's hard enough to use D-BUS correctly (or really, write software in general) as is. > Or you'll slowly start > depending on more and more applications that can't be restarted, which isn't > something you want afaik. I guess the way to frame this is that you cannot automatically restart anything that the desktop depends on for a security update. That includes the kernel, D-BUS, HAL, and X. It's important to note here that even before D-BUS was introduced, we *already* had the problem of some package updates requiring a restart to take effect. The kernel and X being the two major examples. Some other good examples are libpng or gdk-pixbuf. The unique thing about D-BUS is simply that this software runs as a "service", and historically on Unix systems services have been isolated islands totally unrelated to other software, so one could just blindly restart them without worrying about any effect on other software. Of course today even that's not true on the server side with e.g. Apache talking to PostgreSQL. > The same for when the dbus dies It should never die. Any more than your kernel dies. Applications aren't written to handle kernel failures, nor should they attempt to handle dbus failures. D-BUS has an extensive test suite, and was written with correctness very much in mind. > (or restarts). This is just a bug in package upgrade scripts. > This doesn't have to be perfect > for everything, a dbus restart should still be something very rare. For debian > stable users it's only when there was a security update for example. Your users will learn to avoid (or at least be unhappy about) security updates if it means their desktop breaks. > The session bus isn't restarted and shouldn't. Actually I think the session bus is the most interesting from a desktop security perspective: http://verbum.org/selinux/6uadec/6uadec.odp > If dbus is upgraded for security > reasons then the users should restart the session, First of all, how do your users know to do that? We as distributors (I work on Fedora) need to solve the problem of package updates needing to notify the user of further action. Secondly, I've been using the term "reboot" loosely here; it includes just restarting X, which to a desktop user has the same effect as a reboot, it's just a bit faster.
Attachment:
signature.asc
Description: This is a digitally signed message part