Networkmanager service is shutdown too early

[Alan Cox]

On Sun, Jun 01, 2008 at 09:14:37AM -0400, Dan Williams wrote:
> 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.

No. This is a myth.

It is *desirable* to resynchronize state. Dbus clients come and go and get
restarted (or do you want to argue the farcical 'any dbus connected
service cannot be restarted' in which case have a spade and keep digging)

> > - 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.

For 99% of cases if dbus sent a 'dbus restart' message (or the dbus library
did that) then application behaviour would be acceptable but not ideal if

- Applications ignored it
- Some applications just restarted themselves from scratch

Almost no work required

> 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.

Which is fine. In a proper model NM takes a "dbus exploded" message from
the support library and either restarts itself or reconfigures.

> > "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.

For the complex cases like changing nautilus icons agreed but for the 99%
case the 'I missed it' and 'restart' responses are both better than praying
it doesn't occur.

Another approach of course would be to hang a persistant state daemon off
dbus which is the way a lot of object models actually work and which can
answer "last state of X was" - that also helps sort out a pile of runtime
ordering issues.

Alan