NetworkManager: відключена мережа при відправці системи в режим сну

Коли я призупиняю свій ноутбук, NetworkManagerвідключає бездротову мережу (в nm-manager.c:do_sleep_wake).

Однак я хотів би все-таки користуватися мережею дуже короткий час (щоб відключити cifsкріплення, що в іншому випадку зробить мою систему непридатною під час відновлення).

Як зробити так, щоб NetworkManager не відключити свою мережу? Чи можна зачекати кілька секунд (або поки щось не спрацьовує; або блокування буде відпущене)?

Пов’язано: pm-utils: Немає мережі в призупинених сценаріях?

журнал налагодження:

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: Щоб зрозуміти, наявність скриптів /etc/pm/sleep.dне допомагає, оскільки мережа вже відключена, як тільки сценарій виконується.

Я не знаю, чи це стандарт, але в Ubuntu є сценарій, який запускається перед тим, як призупинити / після відновити в /etc/pm/sleep.dі в /usr/lib/pm-utils/sleep.d. У моїй системі здається, що мережа відключена /usr/lib/pm-utils/sleep.d/60_wpa_supplicant.

Ви можете написати сценарій, наприклад, /etc/pm/sleep.d/10-umountщоб демонтувати свої акції перед тим, як призупинити. Структура цих сценаріїв така:

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

Зауважте, що якщо сценарій повертає загальну помилку, призупинення припиняється, тому подбайте про це (особливо це ви, як і я, використовуєте для закриття кришки та зберігання ноутбука подалі ...). Для написання більш складних речей, дякуючи Самуелю Петру за коментар:

ви можете повернути помилку, не припиняючи призупинення, повернувши одне із спеціальних значень, визначених у /usr/lib/pm-utils/pm-functions: $NA "не застосовується", $DX"відключено" та $NX"не виконується". Дивіться hook_exit_statusфункцію в сценарії функцій pm

Ви навіть можете відновити їх після автоматичного відновлення; з тут я виявив , що:

Якщо ви хочете зробити щось специфічне для вашої установки під час призупинення або сплячого режиму, ви можете легко поставити власний гачок у /etc/pm/sleep.d. Гаки в цьому каталозі будуть викликані в алфавітному порядку під час призупинення (тому їхні імена починаються з двох цифр, щоб зробити замовлення явним) та у зворотному порядку під час відновлення.

Так що введення в один і той же сценарій umountі mount commandповинно працювати (в тимчасовому режимі воно виконується перед відключенням мережі, а в резюме після цього).

Посилання на ваше запитання показова; моя інтерпретація полягає в тому, що якщо NetworkManager вимикає мережу перед запуском скриптів на рівні 00-50, це помилка --- принаймні, якщо з'єднання позначено як системне з'єднання (у Налаштуваннях мережі -> Параметри -> Ідентифікація - > Доступно для іншого користувача).

Спираючись на те, що сказав @ensc, ви можете замість цього прослухати сигнал D-Bus (системний сеанс) самостійно. Загальний робочий процес із org.freedesktop.login1.Managerінтерфейсом буде таким:

1. гальмують системний сон (можливо, також відключення) при Inhibit(what, who, why, mode)
   • what: sleepабоshutdown:sleep
   • who: unmount_cifsабо як ви назвете свій сценарій
   • why: unmounting cifs X before suspend ...або еквівалент
   • mode: delayгальмувати макс. з 5s (за замовчуванням) або blockблокувати на невизначений термін (я б рекомендував перший. Якщо ваш сценарій зупиняється, ваш ноутбук просто ніколи не лягає спати.)
   • це повертає дескриптор файлу, який "утримує" замок
2. тепер ви слухаєте сигнал (и)
   • PrepareForSleep, яка повертається, Trueколи збирається призупинити чи сплячку та Falseвідновити та відтанути)
   • PrepareForShutdown, який повертається, Trueколи збирається відключитись, і повинен повернутися Falseпри включенні живлення (замість цього він також повертається Falseв той же час, коли він повертається, Trueщо для мене не має сенсу, тому я просто ігнорую цю Falseчастину тут; ви, мабуть, вже маєте якийсь сценарій автоматичного автоматизації при запуску системи все одно, чи не так?)
3. як тільки ви закінчите з обробкою Trueсигналу (тобто відключенням), ви відпустите замок, закривши дескриптор файлу (повертається Inhibit(...)), щоб машина могла перейти у режим сну або вимкнення якнайшвидше, не чекаючи цілих 5 секунд ( або навіть на невизначений час у blockрежимі)
4. ви можете обробити Falseсигнал (відновити / відтанути), повторно переглянувши (можливо, спочатку чекайте, коли мережа повернеться), а потім створити новий замок з Inhibit(...)(для наступного сну або відключення)

У Python (2.7) це може виглядати так:

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

У цьому Gist ви знайдете мою обгортку навколо Pidgin для відключення акаунтів чатів у режимі сну та відключення, використовуючи абсолютно той самий підхід.

Дивіться також офіційну документацію freeesktop про замки інгібіторів та logindAPI D-Bus .

Ви можете спробувати з’ясувати, чому nmвимикає пристрої:

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

Коли (як у моєму випадку (Fedora 20)) systemdспрацьовує сигнал, ви можете відмовити його доставці в конфігурації 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>

На жаль, ці правила не дуже дрібні, і це блокує PrepareForSleepсигнал також для інших процесів.

Спробуйте вимкнути послугу перед тим, як призупинити, і почніть заново після відновлення Таким чином:

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