On Tue, Aug 23, 2011 at 3:47 PM, Canek Peláez Valdés <can...@gmail.com> wrote: > On Tue, Aug 23, 2011 at 3:08 PM, Michael Mol <mike...@gmail.com> wrote: >> Because I generally update my desktop system while running X, and on >> at least two occasions, an update killed my X session by restarting >> DBUS on me > > The update don't restart D-Bus: from the dbus-1.4.14 ebuild: > > elog "To start the D-Bus system-wide messagebus by default" > elog "you should add it to the default runlevel :" > elog "\`rc-update add dbus default\`" > elog > elog "Some applications require a session bus in addition to the system" > elog "bus. Please see \`man dbus-launch\` for more information." > elog > ewarn "You must restart D-Bus \`/etc/init.d/dbus restart\` to run" > ewarn "the new version of the daemon." > ewarn "Don't do this while X is running because it will restart your X as > well." > > Emphasising: "Don't do this while X is running because it will restart > your X as well." So I will assume something went terribly wrong when > updating, and again, if that's the case then it's a bug and should be > reported.
I see. Apologies for the snark, but this feels like it leads to a "Setup requires that you restart your computer to continue" situation. (This becomes less and less of an exaggeration as more and more system components choose to route their traffic through D-Bus) > >> On the other hand, sshd handles restarts without killing active sessions. > > Because the daemon state for sshd is tiny compared with the one from > D-Bus. Apples and oranges. That doesn't really enter into it. To me, that means you would want to use something like shared memory (is there any multi-tasking operating system with protected memory which can't mmap?) and rigorous checks and controls for managing that state. Even sqlite can manage that. (Not that I'm suggesting you would use sqlite for tracking D-Bus state, just that you'd look at what they do with locks and integrity checks for guaranteeing integrity on shared memory with multiple consuming processes.) And, yes, upgrades on live data can be a royal PITA. Designing a system which can handle it requires careful attention and testing. The more anal you want to be about it, the more you start talking about writing provable and verifiable code and other stringent debugging, development and testing practices. Yet it's done. Last Friday, I sat at a table with someone who witnessed an IBM tech replace a CPU in a mainframe. Flip a switch, pull out the old part, insert the new part, flip the switch back on, everything's fine. Saturday, I listened to a guy present on how he dynamically reroutes live calls through a VOIP network based on hardware faults. > >> These are solvable problems which DBUS hasn't solved yet for itself. >> High-availability is one of the best-researched fields in computer >> science, but DBUS doesn't handle that case, yet. > > Because it's not as easy as with systemd (which can also reexecute > preserving state) or ssh. D-Bus wants to be a core system service, and *that's* what should be setting its design goals, not how difficult it would be for the system to be worthy of the core. Again, I really don't believe D-Bus is badly-written. I just think its community isn't fully aware of the trends of its position in the system, and what responsibilities it carries. -- :wq
