Как мне использовать ENV {SYSTEMD_USER_WANTS} = в правиле udev?

Question

Я хочу настроить docked.target на моем уровне systemd. Идея состоит в том, чтобы запустить некоторые службы для настройки моих внешних дисплеев.

У меня в настоящее время есть это как мое правило:

SUBSYSTEM=="usb", ACTION=="add", ENV{ID_VENDOR}=="17ef", ENV{ID_MODEL}=="100a", SYMLINK+="tp_mini_dock", TAG+="systemd", ENV{SYSTEMD_USER_WANTS}="docked.target"

Правило обнаруживается очень хорошо (я вижу dev-tp_mini_dock.device когда я пристыкован).

Затем у меня есть это в ~/.config/systemd/user/docked.target (также попытался /etc/systemd/user без удачи):

[Unit]
Description=Docked to ThinkPad Mini Dock
BindTo=dev-tp_mini_dock.device

Но это не начинается, когда я док. Однако, если я вручную запускаю docked.target во время пристыковки, он останавливается, как и ожидалось, когда я отсоединяюсь.

Однако если я использую ENV{SYSTEMD_WANTS}="docked.target" и помещаю файл в /etc/systemd/system/docked.target , цель запускается, как и ожидалось, когда я подключаюсь к док-станции. Проблема в том, что мой экземпляр уровня пользователя не знает об услугах / целях системного уровня.

Какие-нибудь мысли? Я видел несколько других вопросов в сети, и один почти точно такой же, как у меня: https://bbs.archlinux.org/viewtopic.php?pid=1600019

Answer 1

Вы можете попробовать заменить SYSTEMD_USER_WANTS на MANAGER_USER_WANTS . Я не уверен на 100% в этом изменении имени, но, по крайней мере, в systemd-226 больше нет упоминания о SYSTEMD_USER_WANTS в источниках, и, похоже, его заменили на MANAGER_USER_WANTS . По крайней мере, у меня сработало для аналогичного случая.

Answer 2

Хотя я до сих пор не знаю, как работает ENV{SYSTEMD_USER_WANTS} , мне удалось решить мою конкретную проблему после прочтения этого блога.

Оказывается, я могу устанавливать цели как зависимость от устройств. Я изменил файл модуля ~/.config/systemd/user/docked.target на:

[Unit]
Description=Docked to ThinkPad Mini Dock
BindsTo=dev-tp_mini_dock.device
After=dev-tp_mini_dock.device

[Install]
WantedBy=dev-tp_mini_dock.device

и мой удев правит:

SUBSYSTEM=="usb", ACTION=="add", ENV{ID_VENDOR}=="17ef", ENV{ID_MODEL}=="100a", SYMLINK+="tp_mini_dock", TAG+="systemd"

и затем включите его с помощью systemctl --user enable docked.target .

Теперь, когда я подключаю его, правило udev создает устройство systemd, которое, в свою очередь, запускает цель. Затем опция BindsTo гарантирует, что когда устройство исчезнет (отключится), цель будет остановлена.

Мне пришлось сделать какую-то бессмысленную магию, чтобы заставить это работать, когда я вхожу в систему с подключенной док-станцией. Можно было бы предположить, что простого добавления default.target к WantedBy и After будет достаточно ... Я добавлю ссылку на блог после того, как напишу.

Answer 3

Мужчина... Эта проблема заставила меня заболеть, что за ошибка!

В моем случае я хотел прослушать события HDMI (горячее подключение монитора) и нашел способ обойти эту проблему. Я подумал, ну, если этот udev каким-то образом узнает, что он запустил службу с тем или иным именем и отказывается делать это снова, то давайте заставим поверить, что он запускает новую службу каждый раз. Все глаза на соответствующее событие udev :

UDEV  [19214.534185] change   /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 (drm)
ACTION=change
DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
ID_FOR_SEAT=drm-pci-0000_01_00_0
ID_PATH=pci-0000:01:00.0
ID_PATH_TAG=pci-0000_01_00_0
MAJOR=226
MINOR=0
SEQNUM=3364
SUBSYSTEM=drm
USEC_INITIALIZED=3280572

и обратите внимание на SEQNUM . Он меняется на каждом новом событии, и это именно то, что мы хотим:

ACTION=="change", SUBSYSTEM=="drm", ENV{HOTPLUG}=="1", ENV{SYSTEMD_USER_WANTS}+="monitor-hotplug@$env{SEQNUM}.service", TAG+="systemd"

Работает как шарм даже для ~/.config/systemd/user/monitor-hotplug@.service . Надеюсь, ваши события также имеют SEQNUM или что-то подобное.