From: "Canek Peláez Valdés" <caneko@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: DBUS [was] Re: [gentoo-user] systemd
Date: Tue, 23 Aug 2011 16:53:13 -0400 [thread overview]
Message-ID: <CADPrc83-m_HY0GTqYg6msYuERNhsZBwys=A78TsJ5PQqCz+a0Q@mail.gmail.com> (raw)
In-Reply-To: <CA+czFiD1cvPkJbwdc=q2McQNc7P6Ke4RwWCUhozbDDAHXXp2kg@mail.gmail.com>
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
next prev parent reply other threads:[~2011-08-23 20:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-23 18:35 DBUS [was] Re: [gentoo-user] systemd Michael Mol
2011-08-23 18:57 ` Canek Peláez Valdés
2011-08-23 19:08 ` Michael Mol
2011-08-23 19:47 ` Canek Peláez Valdés
2011-08-23 20:18 ` Michael Mol
2011-08-23 20:53 ` Canek Peláez Valdés [this message]
2011-08-24 5:40 ` Michael Mol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADPrc83-m_HY0GTqYg6msYuERNhsZBwys=A78TsJ5PQqCz+a0Q@mail.gmail.com' \
--to=caneko@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox