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

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

[Michael Mol]

(renaming, because it feels like a rant thread is inevitable)

On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Tue, Aug 23, 2011 at 1:17 PM, Stroller
>> Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros.
>
> I don't see the problem with D-Bus. It's small (the only hard
> dependency it has is an XML parser), and it provides the Linux/UNIX
> (de facto) standard interprocess communication system.

My chief gripe with D-Bus is that I've had X sessions disappear out
from under me as a consequence of the daemon being restarted. Having a
single point of failure like that is very, very scary. Otherwise, I
like what it tries to do.

-- 
:wq

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

[Canek Peláez Valdés]

On Tue, Aug 23, 2011 at 2:35 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Tue, Aug 23, 2011 at 1:17 PM, Stroller
>>> Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros.
>>
>> I don't see the problem with D-Bus. It's small (the only hard
>> dependency it has is an XML parser), and it provides the Linux/UNIX
>> (de facto) standard interprocess communication system.
>
> My chief gripe with D-Bus is that I've had X sessions disappear out
> from under me as a consequence of the daemon being restarted. Having a
> single point of failure like that is very, very scary. Otherwise, I
> like what it tries to do.

Restarting or dying? If it's dying, it's a bug and should be reported.
I haven't had a crash in dbus in years, and I think pretty much
everyone agrees it's pretty stable nowadays. It even tries to handle
gracefully thins like out-of-memory errors and things like that.

If it's restarting, why on earth will someone restart the system bus
with active X sessions? If the dbus daemon is restarted, it has to
kick all the apps from the bus, including the session manager.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

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

[Michael Mol]

On Tue, Aug 23, 2011 at 2:57 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Tue, Aug 23, 2011 at 2:35 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Tue, Aug 23, 2011 at 1:17 PM, Stroller
>>>> Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros.
>>>
>>> I don't see the problem with D-Bus. It's small (the only hard
>>> dependency it has is an XML parser), and it provides the Linux/UNIX
>>> (de facto) standard interprocess communication system.
>>
>> My chief gripe with D-Bus is that I've had X sessions disappear out
>> from under me as a consequence of the daemon being restarted. Having a
>> single point of failure like that is very, very scary. Otherwise, I
>> like what it tries to do.
>
> Restarting or dying? If it's dying, it's a bug and should be reported.
> I haven't had a crash in dbus in years, and I think pretty much
> everyone agrees it's pretty stable nowadays. It even tries to handle
> gracefully thins like out-of-memory errors and things like that.

I have no doubt a stellar amount of work has been done to gracefully
handle problem scenarios.

>
> If it's restarting, why on earth will someone restart the system bus
> with active X sessions? If the dbus daemon is restarted, it has to
> kick all the apps from the bus, including the session manager.

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

On the other hand, sshd handles restarts without killing active sessions.

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.

-- 
:wq

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

[Canek Peláez Valdés]

On Tue, Aug 23, 2011 at 3:08 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Tue, Aug 23, 2011 at 2:57 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Tue, Aug 23, 2011 at 2:35 PM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>> On Tue, Aug 23, 2011 at 1:17 PM, Stroller
>>>>> Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros.
>>>>
>>>> I don't see the problem with D-Bus. It's small (the only hard
>>>> dependency it has is an XML parser), and it provides the Linux/UNIX
>>>> (de facto) standard interprocess communication system.
>>>
>>> My chief gripe with D-Bus is that I've had X sessions disappear out
>>> from under me as a consequence of the daemon being restarted. Having a
>>> single point of failure like that is very, very scary. Otherwise, I
>>> like what it tries to do.
>>
>> Restarting or dying? If it's dying, it's a bug and should be reported.
>> I haven't had a crash in dbus in years, and I think pretty much
>> everyone agrees it's pretty stable nowadays. It even tries to handle
>> gracefully thins like out-of-memory errors and things like that.
>
> I have no doubt a stellar amount of work has been done to gracefully
> handle problem scenarios.
>
>>
>> If it's restarting, why on earth will someone restart the system bus
>> with active X sessions? If the dbus daemon is restarted, it has to
>> kick all the apps from the bus, including the session manager.
>
> 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.

> 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.

> 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. The state that D-Bus handles can be really,
really big, because is a *generic* IPC. Not like Secure Shell, which
only handles one type of session and a very limited set of messages.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

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

[Michael Mol]

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

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

[Canek Peláez Valdés]

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

And I think it's OK. To upgrade the kernel, we need a computer
restart. To upgrade the system bus, we need a system bus (service)
restart. To upgrade the session bus, we need a session restart
(logout/login). Nobody is saying that a bus restart needs a complete
computer restart (although I'm pretty sure some distros would do that
by default).

>>> 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.)

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.

> 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.

> 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.

> 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.

Just my 0.02 ${CURRENCY}.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

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

[Michael Mol]

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