DBus reconnect support (initial attempt)

[Colin Walters]

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

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
carefully, etc.

> 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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050315/bb5b842c/attachment.pgp