After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 683932 - NetworkManager- in daemon mode ignores SIGTERM
NetworkManager- in daemon mode ignores SIGTERM
Product: NetworkManager
Classification: Platform
Component: general
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Reported: 2012-09-13 09:15 UTC by Alexandre Rostovtsev
Modified: 2013-04-30 12:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

proposed patch (1.02 KB, patch)
2012-09-13 09:48 UTC, Alexandre Rostovtsev
none Details | Review

Description Alexandre Rostovtsev 2012-09-13 09:15:44 UTC
In NetworkManager-, 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 and earlier versions which respected SIGTERM in daemonized mode.
Comment 1 Alexandre Rostovtsev 2012-09-13 09:48:51 UTC
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.
Comment 2 Jiri Klimes 2012-09-17 12:53:44 UTC
The patch has been pushed to master as 64342a313ef497fca8a4fb7567900d4a1460065f

Thank you very much!
Comment 3 Marius Kotsbak 2013-04-02 06:51:53 UTC
Any plans for backporting the fix to 0.6 and 0.5 branches?
Comment 4 Ernie_07 2013-04-30 12:46:01 UTC
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