Re: Stop nm-system-settings when NM is stopped

[Dan Williams <dcbw redhat com>]

On Tue, 2009-04-21 at 13:39 +0200, Alexander Sack wrote:
> On Tue, Apr 21, 2009 at 12:23:01PM +0100, Marc Herbert wrote:
> >
> >>> Thoughts, Opinions?
> >
> >> Technically, NetworkManager doesn't start nm-system-settings daemon
> >> (nor wpa_supplicant), so I don't think it should kill it either. It's
> >> a DBus activated service and it should have the same life cycle as
> >> DBus system daemon. Also, requiring NM/system settings restarts to
> >> modify a single NMConnection doesn't sound very nice. So in my
> >> opinion, you should just implement monitoring like keyfile,rh, and
> >> opensuse plugins do.
> 
> Seems that reply didnt got to mailing list (at least i didnt get
> it).
> 
> Isnt NetworkManager supposed to give the system service a few seconds
> time to reappear before considering all previously used connections
> gone? If not, we should consider to implement that.

Maybe; but we shouldn't be killing nm-system-settings on a whim.

> Monitoring and applying modified config files straight away is
> considered impolite by admins and i think its really bad practice that
> keyfile,rh do that. Usually admins want to decide about the "when"
> after they edited a config file. Think about your webserver and
> mailserver monitoring config files and and just reloading config when
> the admin saves the file - in whatever state it might be at that point
> ;).

If the admin doesn't write the file out, it won't get noticed.  The
inotify code should be using IN_CLOSE_WRITE to only pick changes up when
the file is actually written out and closed.

The solution here is to not write out half-baked config files, really.
Or write out a temp config file, and move that to the acutal production
config file *when it's ready*.

You don't make live edits to web pages, do you?  Same sort of thing.

> In turn, the init reload/restart mechanism is what admins are used to
> do; why wouldn't we want to suppor that semantic instead?

Just because it's always been done that we should continue? :) Perhaps,
but not *necessarily*.

dan