Re: DBus reconnect support (initial attempt)

["Bill Rugolsky Jr." <brugolsky telemetry-investments com>]

On Mon, Mar 14, 2005 at 10:21:54PM -0500, Havoc Pennington wrote:
> I *strongly* agree with Colin's post for the session dbus. It's crazy to
> consider restarting that thing.
 
Fair enough.

> For the system dbus, I can imagine that the number of apps involved is
> small enough that we might adapt most of them to handle the restart...
> but I'm not optimistic.
> 
> So apps are welcome to try handling it, but I just would not expect it
> to ever actually work reliably on real life systems.

Just my two cents, I haven't followed the development, but ...
 
The system dbus, if used as envisioned, will fulfill a special adjunct role
w.r.t.  the kernel similar to init.

If it is some huge bloated behemoth that may die due to bugs, or gets
killed by the OOM-killer, etc., then apps must reliably reconnect.  If
it _can_ crash, it _will_ crash, quite often for certain workloads.  And
then we've got something only marginally better than Windows.

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.

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, then it will be unusable
for such low-level tasks, and those who care about them will have to go
back and engineer something better on top of netlink and other low-level
facilities.

Regards,

	Bill Rugolsky