DBus reconnect support (initial attempt)
walters at verbum.org
Tue Mar 15 07:57:00 PST 2005
On Tue, 2005-03-15 at 08:01 -0500, Bill Rugolsky Jr. wrote:
> If it is some huge bloated behemoth that may die due to bugs,
Any software can crash due to bugs. The same is true for someone
writing some hypothetical D-BUS replacement on top of netlink or
But you might notice that the D-BUS authors care a lot about checking
for bugs; for example, there's a lot of unit tests, patches are reviewed
> or gets
> killed by the OOM-killer, etc.,
The OOM killer is really just a last gasp for the kernel; I've seen
several kernel hackers like Alan Cox say that it isn't even guaranteed
to kick in or work. I do think we should be able to exclude certain
applications from it though like the system bus.
> then apps must reliably reconnect. If
> it _can_ crash, it _will_ crash, quite often for certain workloads.
D-BUS is designed to be reliable.
Anyways, I'm confused as to how we started talking about reliability in
a conversation about upgrades.
> If it is compact, simple, and never crashes, then a less complex model
> fault model may be appropriate. But, at a minimum, I'd expect the
> system dbus to be able to checkpoint its state and rexec itself, with
> file-descriptors held open across exec() if necessary. It certainly
> wouldn't be the first daemon with such requirements.
That's not written though, and we need to work with what we have now.
> I'd like to see all of networking handled dynamically, so that the Linux
> networking stack can be used to its full potential. The same is true
> for storage mgmt (which looks more like networking every day). But if
> dbus is not going to be as robust as init,
What makes you think it's not?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050315/bb5b842c/attachment.pgp
More information about the dbus