When I suspend my notebook, NetworkManager disables the wireless network (in nm-manager.c:do_sleep_wake).

However, I'd love to still use the network for a very short time (to unmount cifs mounts, that otherwise make my system unusable when resuming).

How can I make NetworkManager not disable my network? Is it possible to wait a few seconds (or until something is triggered; or a lock is released)?

Related: pm-utils: No network in suspend scripts?

debug log:

Feb  8 10:03:23 zenbook NetworkManager[3606]: <debug> [1360314203.373226] [nm-manager.c:3391] upower_sleeping_cb(): Received UPower sleeping signal
Feb  8 10:03:23 zenbook NetworkManager[3606]: <info> sleep requested (sleeping: no  enabled: yes)
Feb  8 10:03:23 zenbook NetworkManager[3606]: <info> sleeping or disabling...
Feb  8 10:03:23 zenbook NetworkManager[3606]: <info> (wlan0): now unmanaged

EDIT: To make it clear, having scripts in /etc/pm/sleep.d does not help as the network already is disabled as soon as a script is executed.

  • Take a look at the power management options and look for something to the effect of "disable networking when computer is suspended"
    – Joseph R.
    Nov 26, 2013 at 10:54
  • There is no such thing. I am using xmonad with Gnome 3.
    – C-Otto
    Nov 26, 2013 at 13:43
  • you mean you're replacing the GNOME Shell with xmonad, but not changing anything else? if so, the power options are in the "Power" pane of gnome-control-center.
    – strugee
    Nov 26, 2013 at 19:35
  • I know. There is no such thing as you said.
    – C-Otto
    Nov 27, 2013 at 7:39
  • The Q you're asking is a bit of an XY problem, The answer I provided to you last year, unix.stackexchange.com/questions/62157/…, wrt creating custom job hooks tied to power management suspend/resume is the way to go here. Trying to prop the network up a little bit longer isn't the right way to approach this problem.
    – slm
    Nov 27, 2013 at 14:33

4 Answers 4


I do not know if it's standard, but in Ubuntu there are script that are run before suspend / after resume in /etc/pm/sleep.d and in /usr/lib/pm-utils/sleep.d. In my system seems that the network is shut down by /usr/lib/pm-utils/sleep.d/60_wpa_supplicant.

You can write a script for example /etc/pm/sleep.d/10-umount to unmount your shares before suspend. The structure of these scripts is like that:

case "${1}" in
                # your command to umount here 
                # (possibly) your command to mount here

Notice that if the script return a generic error the suspend is aborted, so take care of this (especially is you, like me, use to close the lid and store the laptop away... ). To script more complex things, thanks to Samuel Peter for his comment:

you can return an error without aborting the suspend by returning one of the special values defined in /usr/lib/pm-utils/pm-functions : $NA is "not applicable", $DX is "disabled", and $NX is "not executable". See the hook_exit_status function in the pm-functions script

You could even remount them after resume automatically; from here I found that:

If you want to do something specific to your setup during suspend or hibernate, then you can easily put your own hook into /etc/pm/sleep.d. The hooks in this directory will be called in alphabetic order during suspend (that is the reason their names all start with 2 digits, to make the ordering explicit) and in the reverse order during resume.

So putting in the same script the umount and mount command should work (in suspend it is executed before shutting down network, and in resume after that).

The link in your question is revealing; it is my interpretation that if NetworkManager shuts down the network before the scripts at level 00-50 are run it is a bug --- at least if the connection is marked as a system connection (in Network Settings -> Options -> Identity -> Make available to other user).

  • +1 pm-utils should be available on all mainstream distros and is probably installed by default.
    – goldilocks
    Nov 26, 2013 at 17:44
  • 1
    Note that you can return an error without aborting the suspend by returning one of the special values defined in /usr/lib/pm-utils/pm-functions : $NA is "not applicable", $DX is "disabled", and $NX is "not executable". See the hook_exit_status function in the pm-functions script Nov 26, 2013 at 18:46
  • NOTE: This answer an more was provided to the OP on this Q: unix.stackexchange.com/questions/62157/… I think he's looking for something else that doesn't exist wrt NetworkManager.
    – slm
    Nov 27, 2013 at 14:45
  • As I already said in the referenced question, I do not have any network in the scripts (i.e. 10-umount). As soon as any script executes, the network already is down.
    – C-Otto
    Dec 1, 2013 at 12:09
  • 1
    I will investigate the system connection property. EDIT: It already was a system connection.
    – C-Otto
    Dec 1, 2013 at 12:10

Building on what @ensc said, you could instead listen for that D-Bus (system session) signal yourself. The general workflow with the org.freedesktop.login1.Manager interface would be:

  1. inhibit system sleep (maybe also shutdown) with Inhibit(what, who, why, mode)
    • what: sleep or shutdown:sleep
    • who: unmount_cifs or whatever you'll call your script
    • why: unmounting cifs X before suspend ... or equivalent
    • mode: delay to inhibit for a max. of 5s (default) or block to block indefinitely (I would recommend the first. If your script stalls, your notebook will just never go to sleep.)
    • this returns a file descriptor that 'holds' the lock
  2. now you listen for the signal(s)
    • PrepareForSleep, which returns True when about to suspend or hibernate and False when resuming and thawing)
    • PrepareForShutdown, which returns True when about to shutdown and should return False when powering back on (instead it also returns False at the same time it returns True which makes no sense to me, so I would just ignore the False part here; you probably already have some kind of automounting script on system start anyways, don't you?)
  3. as soon as you're done with handling the True signal (i.e. unmounting) you release the lock by closing the file descriptor (returned by Inhibit(...)), so that the machine may go to sleep or shutdown as fast as possible without waiting for the whole 5s (or even indefinitely when in block mode)
  4. you can handle the False signal (resume/thaw) by remounting (maybe first waiting for the network to come back on) and then create a new lock with Inhibit(...) (for the next sleep or shutdown)

In Python (2.7) this could look like:

#!/usr/bin/env python
import os, atexit, dbus, gobject
from dbus.mainloop import glib

def login1ManagerDBusIface():
    system_bus = dbus.SystemBus()
    proxy = system_bus.get_object( 'org.freedesktop.login1',
                                  '/org/freedesktop/login1' )
    login1 = dbus.Interface( proxy, 'org.freedesktop.login1.Manager')
    return login1

def sleepShutdownInhibit():
    login1 = login1ManagerDBusIface()
    fd = login1.Inhibit( 'shutdown:sleep', 'unmount_cifs',
                         'Unmounting before suspend/shutdown ...',
                         'delay' )
    return fd

def take_lock():
    global FD
    FD = sleepShutdownInhibit()

def remove_lock():
    global FD
    if FD:
        os.close( FD.take() )
        FD = None

def signal_handler(boolean, member=None):
    if boolean:  ## going to suspend/hibernate or shutdown
    else:  ## resume/thaw
        if member == 'PrepareForSleep':

if __name__ == '__main__':
    login1 = login1ManagerDBusIface()
    for signal in ['PrepareForSleep', 'PrepareForShutdown']:
        login1.connect_to_signal(signal, signal_handler,
    loop = gobject.MainLoop()

In this Gist you'll find my wrapper around Pidgin to disconnect IM accounts on sleep and shutdown, using exactly the same approach.

See also the official freedesktop documentation on Inhibitor Locks and the logind D-Bus API.

  • I'm looking at doing something similar (for unix.stackexchange.com/q/337853). This sounds promising, but surely it is racing with NetworkManager which is doing the same thing? What happens if my network-dependent script takes longer to run than NetworkManager takes to stop the network?
    – David
    Aug 5, 2017 at 5:41
  • Tried it out (github.com/davidn/av) and it seems to work!
    – David
    Aug 6, 2017 at 18:31

You could try to find out why nm is shutting down the devices:

dbus-monitor --system &
nmcli g logging level DEBUG
--> trigger suspend

When (like in my case (Fedora 20)), systemd is triggering the signal, you can deny its delivery in the dbus configuration:

---- /etc/dbus-1/system.d/99-my-suspend.conf ---
        <policy user="root">
                <deny receive_interface="org.freedesktop.login1.Manager"

Unfortunately, these rules are not very fine grained and it will block the PrepareForSleep signal for other processes too.


Try to shutdown service before suspend and start again after resume. Like that:


  • What do you mean? Should I stop the network manager service? I do not understand how that would help.
    – C-Otto
    Nov 26, 2013 at 13:45
  • welcome to Stack Exchange! please don't give answers that are basically single links. if possible, you should paraphrase the material you linked to, otherwise, copying and pasting is fine as long as you attribute it. and again, welcome!
    – strugee
    Nov 26, 2013 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .