NetworkManager: réseau désactivé lors de l'envoi du système en veille

Lorsque je suspends mon ordinateur portable, NetworkManagerdésactive le réseau sans fil (in nm-manager.c:do_sleep_wake).

Cependant, j'aimerais toujours utiliser le réseau pendant très peu de temps (pour démonter les cifssupports, ce qui rendrait mon système inutilisable lors de la reprise).

Comment puis-je faire pour NetworkManager ne pas désactiver mon réseau? Est-il possible d'attendre quelques secondes (ou jusqu'à ce que quelque chose se déclenche ou qu'un verrou soit libéré)?

Connexes: pm-utils: aucun réseau dans les scripts de suspension?

journal de débogage:

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: Pour être clair, avoir des scripts /etc/pm/sleep.dn'aide pas car le réseau est déjà désactivé dès qu'un script est exécuté.

Je ne sais pas si c'est standard, mais dans Ubuntu il y a des scripts qui sont exécutés avant la suspension / après la reprise dans /etc/pm/sleep.det en /usr/lib/pm-utils/sleep.d. Dans mon système semble que le réseau est arrêté par /usr/lib/pm-utils/sleep.d/60_wpa_supplicant.

Vous pouvez par exemple écrire un script pour /etc/pm/sleep.d/10-umountdémonter vos partages avant de suspendre. La structure de ces scripts est la suivante:

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

Notez que si le script retourne une erreur générique, la suspension est abandonnée, alors faites attention à cela (surtout vous, comme moi, utilisez pour fermer le couvercle et ranger l'ordinateur portable ...). Pour écrire des choses plus complexes, merci à Samuel Peter pour son commentaire:

vous pouvez renvoyer une erreur sans abandonner la suspension en renvoyant l'une des valeurs spéciales définies dans /usr/lib/pm-utils/pm-functions: $NA est "non applicable", $DXest "désactivé" et $NX"n'est pas exécutable". Voir la hook_exit_statusfonction dans le script pm-functions

Vous pouvez même les remonter automatiquement après la reprise; à partir d' ici j'ai trouvé que:

Si vous voulez faire quelque chose de spécifique à votre configuration pendant la suspension ou l'hibernation, vous pouvez facilement mettre votre propre hook dans /etc/pm/sleep.d. Les hooks de ce répertoire seront appelés dans l'ordre alphabétique lors de la suspension (c'est la raison pour laquelle leurs noms commencent tous par 2 chiffres, pour rendre l'ordre explicite) et dans l'ordre inverse lors de la reprise.

Donc, mettre le même script le umountet mount commanddevrait fonctionner (en suspension, il est exécuté avant la fermeture du réseau, et en reprise après cela).

Le lien dans votre question est révélateur; c'est mon interprétation que si NetworkManager arrête le réseau avant que les scripts au niveau 00-50 soient exécutés, c'est un bug --- au moins si la connexion est marquée comme connexion système (dans Paramètres réseau -> Options -> Identité - > Rendre disponible à un autre utilisateur).

En vous basant sur ce que @ensc a dit, vous pouvez plutôt écouter ce signal D-Bus (session système) vous-même. Le flux de travail général avec l' org.freedesktop.login1.Managerinterface serait:

1. inhiber le sommeil du système (peut-être aussi l'arrêt) avec Inhibit(what, who, why, mode)
   • what: sleepoushutdown:sleep
   • who: unmount_cifsou ce que vous appellerez votre script
   • why: unmounting cifs X before suspend ...ou équivalent
   • mode: delayinhiber pendant max. de 5 s (par défaut) ou blockà bloquer indéfiniment (je recommanderais le premier. Si votre script se bloque, votre ordinateur portable ne se mettra jamais en veille.)
   • cela renvoie un descripteur de fichier qui «détient» le verrou
2. maintenant vous écoutez le (s) signal (s)
   • PrepareForSleep, qui revient Truequand sur le point de suspendre ou d'hiberner et Falselors de la reprise et de la décongélation)
   • PrepareForShutdown, qui revient au Truemoment de l'arrêt et devrait revenir Falselors de la remise sous tension (à la place, il revient également Falseen même temps qu'il revient, Truece qui n'a aucun sens pour moi, donc je voudrais simplement ignorer la Falsepartie ici; vous avez probablement déjà une sorte de script de montage automatique sur le démarrage du système de toute façon, non?)
3. dès que vous avez fini de gérer le Truesignal (c'est-à-dire le démontage), vous libérez le verrou en fermant le descripteur de fichier (renvoyé par Inhibit(...)), afin que la machine puisse se mettre en veille ou s'arrêter le plus rapidement possible sans attendre les 5 secondes entières ( ou même indéfiniment en blockmode)
4. vous pouvez gérer le Falsesignal (reprise / décongélation) en remontant (peut-être en attendant d'abord que le réseau se remette en marche) puis en créant un nouveau verrou avec Inhibit(...)(pour la prochaine mise en veille ou l'arrêt)

En Python (2.7), cela pourrait ressembler à:

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

Dans ce Gist, vous trouverez mon enveloppe autour de Pidgin pour déconnecter les comptes de messagerie instantanée en veille et à l'arrêt, en utilisant exactement la même approche.

Voir également la documentation officielle de freedesktop sur les verrous inhibiteurs et l' logindAPI D-Bus .

Vous pouvez essayer de découvrir pourquoi l' nmarrêt des appareils:

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

Lorsque (comme dans mon cas (Fedora 20)), systemddéclenche le signal, vous pouvez refuser sa livraison dans la configuration dbus:

---- /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>

Malheureusement, ces règles ne sont pas très fines et elles bloqueront également le PrepareForSleepsignal pour d'autres processus.

Essayez d'arrêter le service avant de suspendre et de recommencer après la reprise. Comme ça:

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