Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
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 '13 at 10:54
    
There is no such thing. I am using xmonad with Gnome 3. –  C-Otto Nov 26 '13 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 '13 at 19:35
    
I know. There is no such thing as you said. –  C-Otto Nov 27 '13 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 '13 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:

#!/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).

share|improve this answer
    
+1 pm-utils should be available on all mainstream distros and is probably installed by default. –  goldilocks Nov 26 '13 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 –  Samuel Peter Nov 26 '13 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 '13 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 '13 at 12:09
1  
I will investigate the system connection property. EDIT: It already was a system connection. –  C-Otto Dec 1 '13 at 12:10

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.

share|improve this answer

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.

share|improve this answer

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

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

share|improve this answer
    
What do you mean? Should I stop the network manager service? I do not understand how that would help. –  C-Otto Nov 26 '13 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 '13 at 19:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.