NetworkManager: disabled network when sending system to sleep

Question

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.

Answer 1

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:

#!/bin/sh
#
case "${1}" in
        suspend|hibernate)
                # your command to umount here 
                ;;
        resume|thaw)
                # (possibly) your command to mount here
                ;;
esac

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).

Answer 2

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
        ## PLACE YOUR UNMOUNT STUFF HERE
        remove_lock()
    else:  ## resume/thaw
        if member == 'PrepareForSleep':
            ## PLACE YOUR MOUNT STUFF HERE
            take_lock()

if __name__ == '__main__':
    take_lock()
    atexit.register(remove_lock)
    login1 = login1ManagerDBusIface()
    for signal in ['PrepareForSleep', 'PrepareForShutdown']:
        login1.connect_to_signal(signal, signal_handler,
                                 member_keyword='member')
    glib.DBusGMainLoop(set_as_default=True)
    loop = gobject.MainLoop()
    loop.run()

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.

Answer 3

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 ---
<busconfig>
        <policy user="root">
                <deny receive_interface="org.freedesktop.login1.Manager"
                      receive_type="signal"
                      receive_member="PrepareForSleep"/>
        </policy>
</busconfig>

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

Answer 4

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

http://oleeekchoff.blogspot.ie/2012/05/restart-modulesservices-after.html