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

[Michael Mol]

On Tue, Aug 23, 2011 at 4:53 PM, Canek Peláez Valdés <caneko@×××××.com> wrote:
> On Tue, Aug 23, 2011 at 4:18 PM, Michael Mol <mikemol@×××××.com> wrote:
> You are right, I stand corrected. And actually, D-Bus is very much
> capable of restart without kicking out sessions (read Havoc
> explanation in http://article.gmane.org/gmane.comp.freedesktop.dbus/7730).
> The problem is that many apps don't handle this correctly, and the
> D-Bus developers choose the "safe" option. If all the apps supported
> gracefully the restart, there would be no problems.

A very, very good writeup which provides a lot of explanation of the
semantics of D-Bus connections. Very helpful, thanks for the link.

What it tells me is that a D-Bus restart needs to be able to be done
without dropping connections. I don't know the specifics of the
bindings between libdbus and the daemon, but a first guess would be to
spin up the upgraded daemon, hand over all live connections, and shut
down the old daemon.

That obviously requires newer daemons being able to talk with older
libdbus (at least until the app itself is restarted), and newer
libdbus being able to talk with older daemons (in the event that an
app hits that vulnerable spot between when  things have been installed
but not upgraded). Obviously, this really depends on how much the
libdbus protocol itself must be able to change going forward.

>
>> 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.
>
> It's a matter of cost-benefit. Given the open source community, I
> think the PITA is not worth it in several cases, D-Bus being one of
> them.

Personally, I suspect the balance will change as there's greater and
greater dependency on D-Bus on long-uptime systems.

>
>> 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.
>
> I have seen those kind of systems. And again, it's a matter of
> cost-benefit: See the difference in budgets for that kind of systems
> and our open source software stack.

True to an extent. I think it was four or five years ago, during the
SCO lawsuit, when someone estimated the value of the Linux kernel at
well over a billion dollars. Many for-profit companies contribute to
the kernel and its architecture. If D-Bus becomes necessary to the
operation of the majority of use cases, I suspect similar contribution
paths will occur there.

>
>> 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.
>
> I think we are fully aware. The thing is, given the community
> resources, D-Bus is good enough, which, as everybody knows, is the
> enemy of (the impossible) perfect.

Very true.

-- 
:wq