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