Як запустити системну службу користувачів для запуску в режимі сну (ака. Призупинення, сплячий режим)?


17

Спираючись на різні джерела, я спільно спіткав ~/.config/systemd/user/screenlock.service:

[Unit]
Description=Lock X session
Before=sleep.target

[Service]
Environment=DISPLAY=:0
ExecStart=/usr/bin/xautolock -locknow

[Install]
WantedBy=sleep.target

Я ввімкнув це за допомогою systemctl --user enable screenlock.service. Але після перезавантаження, входу в систему, призупинення та відновлення (тестування як із systemctl suspendзакритою кришкою, так і з екраномjournalctl --user-unit screenlock.service ) екран не блокується, і в ньому нічого немає . Що я роблю неправильно?

Запуск DISPLAY=:0 /usr/bin/xautolock -locknowблокує екран, як очікувалося.

$ systemctl --version
systemd 215
+PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR
$ awesome --version
awesome v3.5.5 (Kansas City Shuffle)
 • Build: Apr 11 2014 09:36:33 for x86_64 by gcc version 4.8.2 (nobody@)
 • Compiled against Lua 5.2.3 (running with Lua 5.2)
 • D-Bus support: ✔
$ slim -v
slim version 1.3.6

Якщо я запускаю systemctl --user start screenlock.serviceблокування екрана негайно, і я отримую повідомлення журналу journalctl --user-unit screenlock.service, настільки ExecStartчітко це правильно.

Відповідний .xinitrcрозділ :

xautolock -locker slock &

Створення системної служби з тим самим файлом працює (тобто slockє активним при поновленні):

# ln -s "${HOME}/.config/systemd/user/screenlock.service" /usr/lib/systemd/system/screenlock.service
# systemctl enable screenlock.service
$ systemctl suspend

Але я не хочу додавати певний користувальницький файл зовні $HOMEз кількох причин:

  • Послуги користувачів повинні бути чітко відокремлені від системних служб
  • Служби користувачів повинні контролюватися без використання привілеїв суперпользователя
  • Конфігурація повинна легко контролюватися версією

Я використовую дивовижний як менеджер вікон і SLiM як менеджер входу . Я не використовую повне середовище робочого столу, як визначено Arch , а Linux / awesome як середовище робочого столу, як визначено в Wikipedia . Здається, немає нічого подібного до "менеджера настільних ПК" для Linux.
l0b0

Служби користувачів запускаються поза сеансом, тому ваші дані сеансу недоступні для них; вам може бути краще використовувати для цього стандартний сервісний файл: принаймні, щоб протестувати все одно ...
jasonwryan

@jasonwryan Напевно я побачив би якесь повідомлення про помилку в журналі, якби послуга була запущена?
l0b0

Я не знаю: systemd-userвсе ще дуже лускатий; змусити його працювати в рамках сесії за допомогою підходу, який я окреслив, допоможе звузити проблему; це все, що я можу запропонувати.
Jasonwryan

Хоча це не ідеальне рішення (все-таки потрібно керувати дозволами root), ви можете просто використовувати /etc/systemd/system/або $HOME/.local/systemd/systemуникати нічого /usrвручну. Як зазначав @jasonwryan, сеанси користувачів все ще не вважаються якісними показниками виробництва; але вони наближаються.
HalosGhost

Відповіді:


20

sleep.targetє специфічним для системних сервісів. Причина в тому, sleep.targetчи не є чарівна мета, яка автоматично активізується під час сну. Це просто звичайна ціль, яка приводить систему до сну - тому екземпляри "користувача", звичайно, не матимуть еквівалента. (І, на жаль, екземпляри "користувача" в даний час не мають можливості залежати від загальносистемних служб.)

(Це і є весь бізнес "жорсткого кодування $ DISPLAY". Кожного разу, коли ви налаштовуєте параметри сеансу жорсткого коду в ОС, що базується на сильно багатокористувацькому / багатомісному Unix, корінь вбиває кошеня.)

Отже, є два хороших способи зробити це (я пропоную другий):

Спосіб 1

Створіть системну службу (або гачок системного сну (8)), яка змушує системний-логін транслювати сигнал "заблокувати всі сеанси", коли система переходить у режим сну:

ExecStart=/usr/bin/loginctl lock-sessions

Потім у межах свого сеансу X11 (тобто від ~ / .xinitrc) запустіть щось, що реагує на сигнал:

systemd-lock-handler hack &
xss-lock - неробочий сон

(GNOME, Кориця, KDE, Просвіт уже підтримують це.)

Спосіб 2

У межах свого сеансу X11 запустіть щось, що безпосередньо спостерігає за тим, як система лягає спати, наприклад, підключившись до "інгібіторів" systemd-logind.

Вищезгаданий xss-lock насправді робить саме це, навіть не маючи явного сигналу «заблокувати все», тому достатньо, щоб він працював:

xss-lock мерзло &

Вона запуститься, slockяк тільки побачить системний логін, що готується зупинити роботу комп'ютера.


Не могли б ви детальніше розібратися про підтримку Просвітництва та інших людей? Незрозуміло, що саме вони підтримують на самому справі у відповідь.
Павло Шімерда

@ PavelŠimerda: Сигнал "блокування сеансу" від systemd-logind (... весь розділ про це ...) Також я помилявся, e19 насправді не підтримує його.
користувач1686

Дякуємо за інформацію про E19. У відповіді все ще бракує пояснень, що саме підтримують Gnome та інші. Прослуховування сигналу D-Bus системи Systemd (навіть це там не написано) - одне, які дії виконуються в реакції та які дії та як можна налаштувати користувачеві - це інше. Також немає інформації про те, що робить systemd-lock-handler і звідки він походить.
Павло Шімерда

xss-lockзнаходиться в AUR, тому не потрібно створювати його вручну.
l0b0

Це прекрасно працює під тестуванням Debian. Дякуємо за публікацію Цілком прикро, що systemd не дозволяє службам користувачів залежати від системних сервісів ...
cgogolin

-1

systemd-lock-handlerце сценарій Python, який може досягти цього: https://github.com/grawity/code/blob/master/desktop/systemd-lock-handler .

#!/usr/bin/env python
# systemd-lock-handler -- proxy between systemd-logind's "Lock" signal and your
#   favourite screen lock command

from __future__ import print_function
import os, sys, dbus, dbus.mainloop.glib
from gi.repository import GLib

def trace(*args):
    global arg0
    print("%s:" % arg0, *args)

def setup_signal(signal_handler):
    global session_id
    bus = dbus.SystemBus()
    manager = bus.get_object("org.freedesktop.login1", "/org/freedesktop/login1")
    # yecch
    manager = dbus.Interface(manager, "org.freedesktop.login1.Manager")
    session_path = manager.GetSession(session_id)
    session = bus.get_object("org.freedesktop.login1", session_path)
    session.connect_to_signal("Lock", signal_handler)

def handler_dbus_fdo():
    trace("locking session using DBus")
    bus = dbus.SessionBus()
    screensaver = bus.get_object("org.freedesktop.ScreenSaver", "/ScreenSaver")
    screensaver.Lock()

def handler_external():
    global lock_command
    trace("locking session using %r" % lock_command[0])
    os.spawnvp(os.P_NOWAIT, lock_command[0], lock_command)

def main():
    global arg0, lock_command, session_id
    arg0 = sys.argv[0].split("/")[-1]
    lock_command = sys.argv[1:] or ["--dbus"]
    try:
        session_id = os.environ["XDG_SESSION_ID"]
    except KeyError:
        print("error: $XDG_SESSION_ID not set; are you using pam_systemd?",
            file=sys.stderr)
        sys.exit(1)
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
    if lock_command == ["--dbus"]:
        trace("using freedesktop.org DBus API")
        setup_signal(handler_dbus_fdo)
    else:
        trace("using external command %r" % lock_command[0])
        setup_signal(handler_external)
    trace("waiting for lock signals on session %s" % session_id)
    try:
        loop = GLib.MainLoop()
        loop.run()
    except KeyboardInterrupt:
        sys.exit(0)

main()
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.