Как служба сеанса Python DBus узнает, что пользователь вышел из системы?
Скажем, у вас есть служба DBus на шине сеанса (шина для каждого пользователя). Ваш сервис может быть запущен с помощью файла /etc/xdg/autostart/*, или он может запуститься в первый раз, когда какое-либо приложение пытается использовать ваше известное имя сервиса. В любом случае, допустим, что сессионная шина DBus - это процесс, который запускает ваш сервис.
А затем пользователь выходит из системы. Так что же происходит? Отправляет ли DBus какое-либо действие SIG < foo > сигналы к вашим услугам, или это прямо к SIGKILL? Есть ли другой способ узнать, что пользователь выходит из системы? По сути, у меня есть некоторые действия по очистке, которые мне нужно выполнить, в том числе уничтожение подпроцессов, запущенных с subprocess.Popen и multiprocessing.
Теперь вы, прежде чем сказать: «Popen и multiprocessing злые, не используйте их», в моем текущем эксперименте я не использую их. Я просто пытаюсь понять, как служба Python DBus может подключиться к чему-то, что позволяет ей выполнять действия по очистке, какой бы ни была общая архитектура.
Любой совет? Есть примеры? Обратите внимание, что мой пример будет работать в GObject.MainLoop и использует Python3 на Ubuntu Precise (или Quantal).
2 ответа
Если вам нужно работать только под GNOME & amp; Unity, вы должны иметь возможность подключиться к интерфейсу DBus менеджера сеансов . Это не только дает вам сообщение «о выходе из системы» с помощью сигналов QueryEndSession и EndSession, но также позволяет блокировать выход из системы / завершение работы до тех пор, пока вы не закончите очистку, если хотите, через EndSessionResponse. [ 114]
Я не уверен, в какой степени KDE реализует совместимый интерфейс.
Вы можете сделать что-то вроде этого:
bus = dbus.SessionBus()
bus.call_on_disconnection(your_method_to_do_stuff)
Или вы можете подключиться к сигналу NameLost на интерфейсе org.FreeDesktop.DBus. Первый не позволяет передавать дополнительные аргументы, а ваш метод может принимать только объект соединения с шиной в качестве аргумента. Последнее немного сложнее, но, похоже, также не позволяет передавать другие аргументы по вашему собственному усмотрению, и вы ограничены принятием аргументов, которые посылает сам сигнал, который в данном случае является строкой шины сообщений. назовите свой процесс, ранее принадлежавший.
С другой стороны, если после этого ваш процесс останется без изменений, теоретически вы должны получить SIGKILL в какой-то момент.