GNOME Bugzilla – Bug 683932
NetworkManager-0.9.6.0 in daemon mode ignores SIGTERM
Last modified: 2013-04-30 12:46:01 UTC
In NetworkManager-0.9.6.0, if /usr/bin/NetworkManager is started in normal (i.e. daemonized) mode, it refuses to be killed with SIGTERM; "kill $(pidof NetworkManager)" has no effect. In fact, "kill $(pidof NetworkManager)" does not even generate any log messages despite "--log-level=DEBUG --log-domains=CORE". But if /usr/bin/NetworkManager is started with --no-daemon, then after receiving SIGTERM, it correctly prints "caught signal 15, shutting down normally" and successfully shuts itself down. This is a regression relative to 0.9.4.0 and earlier versions which respected SIGTERM in daemonized mode.
Created attachment 224204 [details] [review] proposed patch Found a solution. Commit 217c5bf6 changed the way NetworkManager handled signals; it now masked everything, and handled signals via sigwait(). Unfortunately, the mask was applied in the initial NetworkManager process, before the daemon process got spawned. As a result, the daemon process became unkillable. The attached patch moves the point where the signal mask gets applied to after (optional) daemonization, and allows a daemonized NetworkManager to handle signals as expected.
The patch has been pushed to master as 64342a313ef497fca8a4fb7567900d4a1460065f Thank you very much!
Any plans for backporting the fix to 0.6 and 0.5 branches?
1. Format and label a target Ext4 partition using Desktop 64-bit Ubuntu 12.04 2. Install Desktop Ubuntu 64-bit 12.10 OR 64-bit 13.04 using that target without reformatting it 3. Shut down 4. Restart selecting the newly installed OS 5. Login then shutdown 6. Boot an alternate copy of Ubuntu 7.Fsck the newly installed OS allowing corrections to be made Each time the the newly installed OS is executed and then shutdown, even if execution only consists of logging on, a subsequent fsck will FAIL. I am connected to my ISP via Ethernet and a DSL modem. The problem will NOT occur if I uncheck Enable Networking or unplug the Ethernet cable. This problem does not occur in Ubuntu 12.04 but it does in versions 12.10 and 13.04