[intrepid] network manager does not stop nm-system-settings when stopped

[Stephan Trebels]

Binary package hint: network-manager

When /etc/init.d/NetworkManager stop is executed as root, the nm-system-settings daemon survives, making it impossible to reload static configuration like Debian's /etc/network/interfaces.

network-manager-0.7~~svn20081018t105859

[Alexander Sack (asac)]

maybe NetworkManager reload should do a killall nm-system-settings ... later NM and all sourrounding services probably want to have a dbus API extension to reload configs. but thats definitly 0.7.x or even 0.8.

When we provide this reload thing wwe shoudl take extra care that the "timeout" mechanism implemented prevents auto connections from being created properly ... last time i looked that didnt work and without giving the system settings backend a chance the applet (or maybe even keyfile plugin) created an auto connection.

[Alexander Sack (asac)]

yes. the bug initself is correct too. not sure if we want to make a separate bug out of the reload config one. most likely that would make sense.

[Stephan Trebels (ncubede)]

Wouldn't it be better to use inotify on /etc/network and /etc/network/interfaces to have nm-system-settings be notified of any changes in the file? The same would certainly apply to ifcfg for Fedora and SuSE, i.e. /etc/sysconfig/network-scripts for Fedora-based dists. Then the file(s) can just be reloaded, when changed and the need for a daemon restart is gone.

Why is nm-system-settings coupled with NetworkManager (started implicitely), anyway? Why can't nm-system-settings be explicitely started and stopped from the init.d script with e.g. a dbus-message "nm-system-settings-available" and "nm-system-settings-unavailable" to message state between daemons (to avoid races). Even separate init.d scripts would make sense IMO.

[Alexander Sack (asac)]

Its a difficult question. Inotify is not really something that gives expected behaviours. Usually users want an explicit action to apply config changes. using the init.d reload command is something well known to debian/ubuntu admins so that sounds like the right approavh to me.

Later when we have proper ifupdown command replacements to do the full transition we might reconsider this, but then updates done through inotify shouldnt automatically cause a reconnect, but only get applied next time a device is upped. (similar to the user experience when editing interfaces and running ifupdown).

[Alexander Sack (asac)]

I dont want to migrate the dbus auto activated services back to init.d.

If there are problems we should find proper solutions instead.

[Alexander Sack (asac)]

>Later when we have proper ifupdown command replacements to do the full transition we might reconsider this, but then >updates done through inotify shouldnt automatically cause a reconnect, but only get applied next time a device is upped. >(similar to the user experience when editing interfaces and running ifupdown).

Obviously, we can do this independent from the legacy commands. Only thing we have to ensure is that when system config changes, that the connection doesnt get reset automatically. I expect there to be a bunch of rouch edges we have to sort out before we can do it.

[Stephan Trebels (ncubede)]

The only thing I'd mean to do with inotify is to make the /etc/network/interfaces cache in memory always represent the content of the file at this time. It does not mean, that this cache has to be used right now. The comparison with ifupdown seems to indicate a deferred application has to be one option (probably even the default), but what I always do in sw: "If you don't know for sure which way is the right one, make it configurable".

So, my suggestion would be: pass an if_block ** to the parser instead of keeping the static pointer, to create the cached memory structure on init and on inotify. Keep two pointers in the plugin private data: activeFirstIfBlock and currentFirstIfBlock, i.e. separate pointers to separate caches. If the current one is activated the pointer is null'd, if the active one is replaced, it is destroyed.

I guess I'll make a proposal in patch form ;-)

could nm-tool be extended to have some useful introspection commands?
nm-tool plugin ifupdown reload -- reload config of this plugin
nm-tool plugin ifupdown config -- dump config of this plugin
nm-tool plugin ifupdown status -- dump state of this plugin
nm-tool show syslog-level
nm-tool set syslog-level debug
...