GNOME Bugzilla – Bug 547849
Exits when system dbus daemon is restarted
Last modified: 2008-08-15 18:05:21 UTC
Steps to reproduce: While upgrading my system, the dbus system daemon was restarted. This caused nm-applet to exit. It didn't appear to crash, it just stopped running. Stack trace: Other information:
Distros should not be restarting the bus on upgrade of the dbus package. NM supports bus reconnections when it's been kicked off because of doing something bad, but does not support bus reconnections if dbus itself goes away.
Is that you speaking as a maintainer of dbus, or as a developer of a dbus client? Also, dbus clients should gracefully handle this kind of stuff instead of leaving the user scratching his head wondering WTF has happened to his system.
OS vendors should not restart the system bus. http://mail.gnome.org/archives/networkmanager-list/2005-March/msg00022.html
the user wouldn't need to scratch his/her head if the distro did not restart the dbus service on a package upgrade. the bus is _not_ meant to be restarted on-the-fly. this is also the view of upstream dbus maintainers and has always been the view of upstream dbus maintainers. there are way too many pieces here on the bus that NM talks to, and the code for doing state resynchronization after a bus restart would be hugely prohibitive when the bus should just not be restarted in the first place.
And yet, this user *is* left scratching his head. Great.
Debian either needs to fix their dbus package, *or* actually help provide patches.
I've filed a bug requesting that the daemon not be restarted on package upgrades. It can be found at <http://bugs.debian.org/495238>.
I've filed a bug requesting that the daemon not be restarted on package upgrades. It can be found at <http://bugs.debian.org/495257>.
More elaboration on the problem, for future reference / in case people debate more: If we wanted to fix this, the right approach is to have functionality in libdbus / dbus bindings so that on startup, an app registers an "on connect to bus" handler. Then in the "on connect to bus" handler, the app registers a "when I see service xyz" handler. Then in the "when I see xyz" handler, the app sets up state related to service xyz. And so forth. This way, initial startup of the app is handled in callbacks, and the same callback chain happens on reconnect. The binding or dbus library would also deal with connecting in an idle and retrying connection in a timeout, rather than making the app do this. With that async API, I can imagine we could eventually expect most apps to support restart. But right now with the dbus_bus_get() API and so forth, the initial setup is a different codepath from any reconnect handling, and reconnect handling is quite complex (the app would need to keep trying to reconnect in a timeout or something). So complex untested code = never going to work, bottom line. Most app authors don't really understand dbus as it is. The right thing to do for now is to NOT restart the system dbus, because it does NOT work until all apps both have code to handle it, and that codepath is tested (by for example being the same as the normal codepath on startup). If someone went on a campaign to first add sane API for handling startup and reconnect in the same way, and then to use that API in all apps, then eventually it could be OK to restart the system bus in the dbus package. But, it is not currently OK, unless you want the system to be broken. If you shoot yourself in the foot, your foot will have a hole in it.