☰

¿Cómo uso ENV{SYSTEMD_USER_WANTS}= en la regla udev?

tag-icon • tag-icon linux systemd udev
¿Cómo uso ENV{SYSTEMD_USER_WANTS}= en la regla udev?

Quiero configurar un docked.targetsistema en mi nivel de usuario. La idea es ejecutar algunos servicios para configurar mis pantallas externas.

Actualmente tengo esta como regla:

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

La regla se detecta muy bien (puedo ver dev-tp_mini_dock.devicecuando estoy acoplado).

Luego tengo esto ~/.config/systemd/user/docked.target(también lo intenté /etc/systemd/usersin suerte):

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

Pero esto no comienza cuando atraco. Sin embargo, si inicio manualmente docked.targetmientras estoy acoplado, se detiene como se esperaba cuando lo desacople.

Sin embargo, si uso ENV{SYSTEMD_WANTS}="docked.target"y coloco el archivo en /etc/systemd/system/docked.target, el objetivo comienza como se esperaba cuando lo conecto. El problema entonces es que mi instancia de nivel de usuario no conoce los servicios/objetivos a nivel de sistema.

¿Alguna idea? He visto algunas otras preguntas en la red y una casi exactamente como la mía:https://bbs.archlinux.org/viewtopic.php?pid=1600019

Respuesta1

Aunque todavía no sé cómo ENV{SYSTEMD_USER_WANTS}funciona, logré resolver mi problema específico después de leereste blog.

Resulta que puedo instalar objetivos como una dependencia de los dispositivos. Cambié mi archivo de unidad ~/.config/systemd/user/docked.targeta:

[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

y mi regla udev es:

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

y luego habilítelo con systemctl --user enable docked.target.

Ahora, cuando lo conecto, la regla udev crea el dispositivo systemd, que a su vez inicia el objetivo. Luego, la BindsToopción se asegura de que cuando el dispositivo desaparezca (se desconecte) el objetivo se detenga.

Tuve que hacer algo de magia sin sentido para que esto funcionara cuando inicio sesión con la base ya conectada. Uno podría imaginar que simplemente agregar default.targety WantedBysería Aftersuficiente... Agregaré un enlace a un blog después de escribirlo.

Respuesta2

Puedes intentar reemplazar SYSTEMD_USER_WANTScon MANAGER_USER_WANTS. No estoy 100% seguro de este cambio de nombre, pero al menos ya systemd-226no se menciona SYSTEMD_USER_WANTSen las fuentes y parece ser reemplazado por MANAGER_USER_WANTS. Al menos a mí me funcionó para un caso similar.

Respuesta3

Hombre... Ese problema también me enfermó, ¡qué bicho!

En mi caso, quería escuchar eventos HDMI (monitorización en caliente) y encontré un truco para solucionar este problema. Pensé, bueno, si esto udevde alguna manera sabe que inició un servicio con tal o cual nombre y se niega a hacerlo nuevamente, entonces hagamos que crea que inicia un nuevo servicio cada vez. Todos los ojos puestos en el udevevento correspondiente:

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

y observe el SEQNUM. Está cambiando en cada nuevo evento y eso es exactamente lo que queremos:

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

Funciona de maravilla incluso para . Ojalá tus eventos también tengan algo similar.~/.config/systemd/user/[email protected]SEQNUM

información relacionada