NetworkManager: Netzwerk deaktiviert, wenn das System in den Ruhezustand versetzt wird

NetworkManagerDeaktiviert das drahtlose Netzwerk (in nm-manager.c:do_sleep_wake), wenn ich mein Notebook anhalte .

Ich würde das Netzwerk jedoch gerne noch für eine sehr kurze Zeit nutzen (um die Bereitstellung von Bereitstellungen cifsaufzuheben, die mein System ansonsten bei der Wiederaufnahme unbrauchbar machen).

Wie kann ich mein Netzwerk NetworkManager nicht deaktivieren? Kann man einige Sekunden warten (oder bis etwas ausgelöst wird oder eine Sperre aufgehoben wird)?

Verwandte: pm-utils: Kein Netzwerk in Suspend-Skripten?

Austestungsprotokoll:

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

BEARBEITEN: Um es klar zu machen, /etc/pm/sleep.dhilft es nicht , Skripte zu haben , da das Netzwerk bereits deaktiviert ist, sobald ein Skript ausgeführt wird.

Ich weiß nicht, ob es Standard ist, aber in Ubuntu gibt es Skripte, die vor dem Anhalten / nach dem Fortsetzen in /etc/pm/sleep.dund in ausgeführt werden /usr/lib/pm-utils/sleep.d. In meinem System scheint das Netzwerk durch heruntergefahren zu sein /usr/lib/pm-utils/sleep.d/60_wpa_supplicant.

Sie können beispielsweise ein Skript schreiben, um /etc/pm/sleep.d/10-umountdie Bereitstellung Ihrer Freigaben vor dem Anhalten aufzuheben. Die Struktur dieser Skripte ist wie folgt:

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

Beachten Sie, dass, wenn das Skript einen generischen Fehler zurückgibt, die Unterbrechung abgebrochen wird. Achten Sie daher darauf (insbesondere, wenn Sie wie ich den Deckel schließen und den Laptop aufbewahren ...). Um komplexere Dinge zu schreiben, danke an Samuel Peter für seinen Kommentar:

Sie können einen Fehler zurückgeben, ohne die Unterbrechung abzubrechen, indem Sie einen der in /usr/lib/pm-utils/pm-functions: $NA "nicht zutreffend", $DX"deaktiviert" und $NX"nicht ausführbar" definierten Sonderwerte zurückgeben . Siehe die hook_exit_statusFunktion im Skript pm-functions

Sie können sie sogar nach der automatischen Wiederaufnahme automatisch wieder anbringen. von hier fand ich das:

Wenn Sie während des Suspendierens oder Ruhezustands etwas Spezielles für Ihr Setup tun möchten, können Sie ganz einfach Ihren eigenen Hook in /etc/pm/sleep.d einfügen. Die Hooks in diesem Verzeichnis werden während des Suspendierens in alphabetischer Reihenfolge aufgerufen (aus diesem Grund beginnen ihre Namen alle mit zwei Ziffern, um die Reihenfolge explizit zu machen) und während des Lebenslaufs in umgekehrter Reihenfolge.

So setzt im selben Skript das umountund mount commandarbeiten soll (in suspendieren sie vor dem Herunterfahren Netzwerk ausgeführt wird, und in wieder danach).

Der Link in Ihrer Frage ist aufschlussreich. Es ist meine Interpretation, dass wenn NetworkManager das Netzwerk herunterfährt, bevor die Skripte auf Ebene 00-50 ausgeführt werden, dies ein Fehler ist - zumindest wenn die Verbindung als Systemverbindung markiert ist (unter Netzwerkeinstellungen -> Optionen -> Identität - > Anderen Benutzern zur Verfügung stellen).

Aufbauend auf den Aussagen von @ensc können Sie stattdessen selbst auf dieses D-Bus-Signal (Systemsitzung) warten. Der allgemeine Workflow mit der org.freedesktop.login1.ManagerSchnittstelle wäre:

1. Systemschlaf hemmen (möglicherweise auch herunterfahren) mit Inhibit(what, who, why, mode)
   • what: sleepodershutdown:sleep
   • who: unmount_cifsoder wie auch immer Sie Ihr Skript nennen
   • why: unmounting cifs X before suspend ...oder gleichwertig
   • mode: delayfür eine max. von 5s (Standard) oder blockauf unbestimmte Zeit blockieren (ich würde die erste empfehlen. Wenn Ihr Skript blockiert, wird Ihr Notebook einfach nie in den Ruhezustand versetzt.)
   • Dies gibt einen Dateideskriptor zurück, der die Sperre "hält"
2. Jetzt hören Sie auf die Signale.
   • PrepareForSleep, die zurückkehrt, Truewenn sie kurz vor dem Suspendieren oder Winterschlaf steht und Falsewenn sie wieder aufgenommen und aufgetaut wird)
   • PrepareForShutdown, das Truebeim Herunterfahren zurückkehrt und beim Wiedereinschalten zurückkehren sollte False(stattdessen kehrt es auch Falsezur gleichen Zeit zurück, Truedie für mich keinen Sinn ergibt, daher würde ich den FalseTeil hier einfach ignorieren ; Sie haben wahrscheinlich bereits eine Art Automounting-Skript auf Systemstart sowieso, nicht wahr?)
3. Sobald Sie mit der Verarbeitung des TrueSignals fertig sind (dh die Bereitstellung aufheben), lösen Sie die Sperre, indem Sie den Dateideskriptor (zurückgegeben von Inhibit(...)) schließen, damit der Computer so schnell wie möglich in den Ruhezustand versetzt oder heruntergefahren werden kann, ohne auf die gesamten 5 Sekunden zu warten ( oder sogar auf unbestimmte Zeit im blockModus)
4. Sie können das FalseSignal (Fortsetzen / Auftauen) verarbeiten, indem Sie es erneut einbinden (möglicherweise zuerst warten, bis das Netzwerk wieder eingeschaltet wird) und dann eine neue Sperre mit erstellen Inhibit(...)(für den nächsten Ruhezustand oder das nächste Herunterfahren).

In Python (2.7) könnte dies so aussehen:

#!/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 dieser Übersicht finden Sie meinen Wrapper um Pidgin, mit dem Sie IM-Konten beim Ruhen und Herunterfahren mit genau demselben Ansatz trennen können.

Siehe auch die offizielle freedesktop-Dokumentation zu Inhibitor Locks und der logindD-Bus-API .

Sie könnten versuchen herauszufinden, warum nmdie Geräte heruntergefahren werden:

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

Wenn (wie in meinem Fall (Fedora 20)) systemddas Signal ausgelöst wird, können Sie dessen Übermittlung in der dbus-Konfiguration verweigern:

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

Leider sind diese Regeln nicht sehr feinkörnig und blockieren das PrepareForSleepSignal auch für andere Prozesse.

Versuchen Sie, den Dienst vor dem Anhalten herunterzufahren und nach dem Fortsetzen erneut zu starten. So wie das:

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