Re: DBUS [was] Re: [gentoo-user] systemd

[Michael Mol]

On Tue, Aug 23, 2011 at 3:47 PM, Canek Peláez Valdés <caneko@×××××.com> wrote:
> On Tue, Aug 23, 2011 at 3:08 PM, Michael Mol <mikemol@×××××.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