On Fri, 2008-05-30 at 16:06 -0400, Colin Walters wrote: > On Fri, May 30, 2008 at 3:45 PM, Colin Walters <walters@xxxxxxxxxx> > wrote: > On Fri, May 30, 2008 at 3:38 PM, seth vidal > <skvidal@xxxxxxxxxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
