NetworkManager: rete disabilitata quando si invia il sistema in modalità sospensione

Quando sospendo il mio notebook, NetworkManagerdisabilita la rete wireless (in nm-manager.c:do_sleep_wake).

Tuttavia, mi piacerebbe comunque utilizzare la rete per un tempo molto breve (per smontare i cifsmontaggi, che altrimenti renderebbero inutilizzabile il mio sistema quando si riprende).

Come posso fare per NetworkManager non disabilitare la mia rete? È possibile attendere qualche secondo (o finché non viene attivato qualcosa o viene rilasciato un blocco)?

Correlati: pm-utils: Nessuna rete negli script di sospensione?

registro di debug:

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: per chiarire, avere script dentro /etc/pm/sleep.dnon aiuta poiché la rete è già disabilitata non appena viene eseguito uno script.

Non so se è standard, ma in Ubuntu ci sono script che vengono eseguiti prima di sospendere / riprendere in /etc/pm/sleep.de in /usr/lib/pm-utils/sleep.d. Nel mio sistema sembra che la rete sia chiusa /usr/lib/pm-utils/sleep.d/60_wpa_supplicant.

Ad esempio, puoi scrivere uno script per /etc/pm/sleep.d/10-umountsmontare le tue condivisioni prima di sospenderle. La struttura di questi script è così:

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

Nota che se lo script restituisce un errore generico, la sospensione viene interrotta, quindi fai attenzione (specialmente tu, come me, usi per chiudere il coperchio e riporre il laptop ...). Per scrivere cose più complesse, grazie a Samuel Peter per il suo commento:

è possibile restituire un errore senza interrompere la sospensione restituendo uno dei valori speciali definiti in /usr/lib/pm-utils/pm-functions: $NA è "non applicabile", $DXè "disabilitato" e $NX"non eseguibile". Vedi la hook_exit_statusfunzione nello script delle funzioni pm

Potresti anche rimontarli dopo averli ripresi automaticamente; da qui ho scoperto che:

Se vuoi fare qualcosa di specifico per la tua configurazione durante la sospensione o l'ibernazione, puoi facilmente mettere il tuo hook in /etc/pm/sleep.d. Gli hook in questa directory verranno chiamati in ordine alfabetico durante la sospensione (questa è la ragione per cui i loro nomi iniziano tutti con 2 cifre, per rendere esplicito l'ordinamento) e nell'ordine inverso durante il resume.

Quindi inserendo lo stesso script the umounte mount commanddovrebbe funzionare (in sospeso viene eseguito prima di chiudere la rete e dopo riprende).

Il link nella tua domanda è rivelatore; è mia interpretazione che se NetworkManager arresta la rete prima che vengano eseguiti gli script al livello 00-50, è un bug --- almeno se la connessione è contrassegnata come connessione di sistema (in Impostazioni di rete -> Opzioni -> Identità - > Rendi disponibile ad altri utenti).

Basandoti su ciò che ha detto @ensc, puoi invece ascoltare tu stesso quel segnale D-Bus (sessione di sistema). Il flusso di lavoro generale con l' org.freedesktop.login1.Managerinterfaccia sarebbe:

1. inibire la sospensione del sistema (forse anche l'arresto) con Inhibit(what, who, why, mode)
   • what: sleeposhutdown:sleep
   • who: unmount_cifso come chiamerai la tua sceneggiatura
   • why: unmounting cifs X before suspend ...o equivalente
   • mode: delayinibire per un max. di 5 secondi (impostazione predefinita) o blockda bloccare a tempo indeterminato (consiglierei il primo. Se lo script si blocca, il tuo notebook non andrà mai a dormire.)
   • questo restituisce un descrittore di file che "mantiene" il blocco
2. ora ascolti i segnali
   • PrepareForSleep, che ritorna Truequando sta per sospendere o ibernare e Falsequando si riprende e si scongela
   • PrepareForShutdown, che ritorna Truequando sta per spegnersi e dovrebbe tornare Falsequando si riaccende (invece ritorna anche Falsenello stesso momento in cui ritorna Trueche non ha senso per me, quindi ignorerei solo la Falseparte qui; probabilmente hai già una sorta di script di montaggio automatico all'avvio del sistema comunque, vero?)
3. non appena hai finito di gestire il Truesegnale (cioè smontare) rilasci il blocco chiudendo il descrittore di file (restituito da Inhibit(...)), in modo che la macchina possa andare in modalità sleep o spegnimento il più velocemente possibile senza attendere l'intero 5s ( o anche indefinitamente quando in blockmodalità)
4. puoi gestire il Falsesegnale (riprendi / scongelare) rimontando (forse prima aspettando che la rete si riaccenda) e quindi crei un nuovo blocco con Inhibit(...)(per il prossimo spegnimento o spegnimento)

In Python (2.7) questo potrebbe apparire come:

#!/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 questa sintesi troverai il mio wrapper attorno a Pidgin per disconnettere gli account di messaggistica istantanea in modalità sospensione e spegnimento, usando esattamente lo stesso approccio.

Vedi anche la documentazione ufficiale di freedesktop su Inhibitor Locks e l' logindAPI D-Bus .

Potresti provare a scoprire perché nmsta spegnendo i dispositivi:

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

Quando (come nel mio caso (Fedora 20)), systemdsta attivando il segnale, puoi negarne la consegna nella configurazione 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>

Sfortunatamente, queste regole non sono molto precise e bloccheranno il PrepareForSleepsegnale anche per altri processi.

Prova a chiudere il servizio prima di sospenderlo e ricominciare dopo aver ripreso. Come quello:

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