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

[Dan Williams <dcbw redhat com>]

On Wed, 2009-04-22 at 20:05 -0400, Dan Williams wrote:
> 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.

This little rant aside, we *already* have the behavior you're talking
about for connection details.  NM doesn't instant-apply the settings you
change in /etc/network/interfaces, it only applies those the next time
that the connection is activated.

Obviously this isn't the case for the hostname, but I don't have much
sympathy if you get your hostname wrong :)

Also, remember that sysadmins from a text console/SSH aren't the only
things updating these files.  And you don't want to have to code
"restart NM" into *everything* that modifies network config either,
whether it's an administrator, a script, a package, or another network
config utility.

Next, consider the connection editor GUI case.  It edits system
connections too; since that's *always* immediate, there would be a huge
behavioral discrepancy between the connection editor for system
connections, and editing them via text file.  Not helpful.

Again, we pretty much already have the commit-on-demand behavior for
connections, because you either have to yank the cable out and plug it
back in (equivalent to SIGHUP) or else you have to manually reconnect
(also equivalent to SIGHUP).

Dan

> > 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
> 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list