On Fri, 2008-05-30 at 16:06 -0400, Colin Walters wrote:
On Fri, May 30, 2008 at 3:45 PM, Colin Walters
On Fri, May 30, 2008 at 3:38 PM, seth vidal
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
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
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
you could reliably stop the fuse service too; given all the discussion
about nearly unfixable race condititons in rmmod that have
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
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 Sorce * Red Hat, Inc * New York