Networkmanager service is shutdown too early

[Simo Sorce]

On Fri, 2008-05-30 at 16:06 -0400, Colin Walters wrote:
> On Fri, May 30, 2008 at 3:45 PM, Colin Walters <walters at verbum.org>
> wrote:
>         On Fri, May 30, 2008 at 3:38 PM, seth vidal
>         <skvidal at fedoraproject.org> wrote:
>         
>                 
>                 
>                 
>                 Simo's point still holds though. What you've described
>                 above is a better
>                 reason to have not designed nm around dbus not a
>                 reason why we should be
>                 okay with our network services going away when we
>                 restart dbus.
>         
>         If you want your operating system to be held together with
>         shell script, duct tape, and ad-hoc use of Unix domain sockets
>         that's cool, I'd rather have a reliable and stable system.
> 
> Let me reply with something a little less antagonistic - it's just
> frustrating because everyone sees "Oh another daemon, let me reboot
> it" and blames application developers, when it's just too hard of a
> problem to deal with.

So it's hard to "reconnect" if DBUS goes down for any reason ?
That doesn't really speak good for DBUS, because it is sure that for one
reason or another it will go down at some point.
Caliming that DBUS can never be restarted is putting your head under the
sand. Bugs just happen, dbus might explode for who knows what reason,
does it mean the machine should implode as well ?

> DBus actually shares a lot of similarities with SCTP
> (http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol);
> it's a realization that message-oriented (as opposed to
> stream-oriented) is fundamentally more useful to applications.   DBus
> just happens to be implemented in userspace, but that doesn't mean
> it's just another daemon, any more than TCP stacks that live in
> userspace in some old operating system designs could just be restarted
> at any time without any obvious side effects on the system.

Good applications are usually built to reconnect when a transport they
use becomes unavailable. if some network switch breaks for a few seconds
down the road my connections have a good chance of surviving and if when
connectivity is back things keep going as if nothing happened.
In any case apps usually just know how to handle a TCP error and
reconnect. This is because they want to be reliable and not to depend on
a 100% reliable subsystem (because ther eis nothing 100% reliable in
software or in hardware today).

> Speaking of userspace kernel integration, I'd be pretty surprised if
> you could reliably stop the fuse service too; given all the discussion
> about nearly unfixable race condititons in rmmod that have
> (http://lwn.net/Articles/31474/).

That's why I never used Fuse so far for important long lived stuff. I do
not mind it on a desktop to quickly access something, but is not
something I'd use on a server.

> Auditing every program and making them able to cleanly support
> restarts of system services like HAL, NetworkManager, and PackageKit
> would be a huge task,

If it is a huge task we have worst problems, we have apps badly
engineered.

> for similar reasons because these services build up state. It might
> sort of work most of the time, but what you *really* do not want is
> for the system to sometimes break when the user plugs in a USB key
> when the background package upgrade happened to restart the bus at
> just the wrong time.

Corner cases always exist, how probable it is that this will happen ?
Is this a good reason to stick head in the sand and claim DBUS is the
perfect daemon that never dies ? Maybe it is, I have no reason to think
DBUS is not reliable, but on this things I am conservative, and I think
that if a daemon needs patching we shouldn't have to reboot the machine
(or restart half the services which is basically the same).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York