Re: Networkmanager service is shutdown too early

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2008-05-30 at 16:49 -0400, Alan Cox wrote:
> On Fri, May 30, 2008 at 03:33:37PM -0400, Colin Walters wrote:
> > DBus is not the same as any other random software because it is explicitly
> > designed to provide reliable communication *between* components, much like
> > the kernel.  If you restart it at random times that reliability guarantee is
> > destroyed.
> 
> So the questions you should ask are
> - Why does restarting dbus have to be unreliable

It's a communication pipe; restarting D-Bus itself is reliable becuase
it's just like TCP.  Its the transport.  But making what gets
_transported_ reliable is the kicker.

It's exactly like all those Cingular/AT&T dropped call commercials from
a while ago:

http://youtube.com/watch?v=DR26BZUo3Dk
http://youtube.com/watch?v=GEd3pS1jXJ4
http://www.spike.com/video/2839248 (spoof)

Suddenly all the state dependent on a D-Bus service is suspect, because
you have no idea what's going on while the bus is down.  You have to
re-synchronize your state after the bus comes back, and that's not a
simple task.

> - Why isn't there a recovery mechanism

The recovery mechanism would be in each service, because the service
knows whether or not it needs recovery or not, and would know how to
merge/synchronize it's state with the services that it depends on.  Some
don't need to.  But ones with state dependent on other D-Bus services
would.

> - Why does network manager have to do the work itself not the support code

Like above, because NM has specific state, and when D-Bus goes away,
it's communication channels with the daemons that affect that
NM-specific state are gone, and NM can't make any assumptions about
what's happening in any other daemon while the bus is gone.  Maybe your
VPN just came up for rekeying, but the signal got lost because D-Bus
isn't around.  So when the bus comes back, your VPN connection is
already dropped.

Or DHCP re-bound while the bus was down, and your sysadmin changed DNS
servers on you, and the signal from dhclient got lost (because the bus
was down).  Unless you re-do the entire DHCP transaction (or teach
dhclient about dbus properly so it can answer questions without having
to exec() stupid scripts that then re-emit state back over D-Bus) NM
would have no idea that the returned DHCP options had changed.  And thus
your DNS is dead.

> And more fundamentally
> 
> Why the ... are people still writing software which doesn't try and tolerate
> faults that are recoverable to a useful extent.  Yes dbus might have to lose
> a few messages and send everyone a "duh whoops" event so they can recover but
> "oh dear it broke everyone reboot" is not good engineering.

In some cases, it's a cost/benefit analysis.  Is the cost of writing and
maintaining a pile of code that handles a D-Bus restart, which shouldn't
ever happen, worth the benefit?  In some cases, definitely.  In other
cases, probably not.  That isn't an excuse to write crappy software, but
it's certainly not as simple of a problem as you present it.

Dan

> So I'm likewise pleased the Debian people raised a sensible point.
> 
> Alan
> 

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux