La documentación sobre Inhibitor Locks de Systemd y también man systemd-inhibit se extiende mucho para explicar cómo iniciar un proceso de una manera que bloquea algo (por ejemplo, el handle-lid-switch
evento).
No pude encontrar una manera que me permitiera eliminar dicho "bloqueo"/"inhibición"/"bloqueo".
Pregunta: ¿Hay alguna forma de eliminar el systemd-inhibit
? bloqueo, por ejemplo a través de un dbus
mensaje?
Antecedentes: para qué necesitaría quitar un bloqueo inhibidor**
Mi computadora portátil tiene un interruptor de cierre de la tapa de la computadora portátil, que systemd-logind
monitorea y, en caso de que la tapa esté cerrada, suspende la computadora portátil:funcionalidad “close-lid -> suspend
“.
Una vez que la computadora portátil se coloca en su estación de acoplamiento, para hacer que el usuario use una pantalla más grande, el gsd-power de Gnome arbitrariamente (y erróneamente y sin ninguna configuración disponible en Gnome para cambiarlo) decide crear un bloqueo inhibidor, impidiendo la funcionalidad “close-lid -> suspend
” para trabajar.
Saber cómo eliminar un bloqueo de inhibidor me permitiría remediar la configuración errónea realizada por el poder gnome-setting-deamon de Gnome gsd-power
. La configuración de Gnome es incorrecta porque invocó manualmente la suspensión systemctl suspend
no mostró ningún problema.
El bloqueo del inhibidor que me gustaría eliminar, como se indica en systemd-inhibit --list
es esto:
Who: alex (UID 1000/alex, PID 4248/gsd-power)
What: handle-lid-switch
Why: Multiple displays attached
Mode: block
Respuesta aceptada:
De la documentación del desarrollador de los bloqueos inhibidores:
Inhibit() devuelve un valor único, un descriptor de archivo que encapsula
el bloqueo. Tan pronto como se cierra el descriptor de archivo (y todos sus
duplicados), el bloqueo se libera automáticamente. Si el cliente muere
mientras se toma el bloqueo, el kernel cierra automáticamente el descriptor de archivo
para que el bloqueo se libere automáticamente. Un bloqueo de demora
tomado de esta manera debe liberarse lo antes posible al recibir
PrepareForShutdown(true) (ver a continuación), pero, por supuesto, solo después de
la ejecución de las acciones que la aplicación quería retrasar la operación
para en primer lugar.
Probablemente no quieras matar a gsd-power
, por lo que deberá cerrar el descriptor de archivo que encapsula el bloqueo. Lo más probable es que esté en manos de gsd-power
. Obligar a otro proceso a cerrar uno de sus descriptores de archivo no es algo normal y puede causar algunos efectos secundarios dentro de gsd-power
. Pero si quieres hacerlo, lee esta pregunta en Stack Overflow.
En su lugar, puede intentar eliminar gsd-power
permiso para ejecutar la acción DBus org.freedesktop.login1.inhibit-handle-lid-switch
. La página man dbus-daemon(1)
podría ser útil.