¿Cómo puedo ejecutar un comando cuando una unidad de servicio systemd está deshabilitada?

¿Cómo puedo ejecutar un comando cuando una unidad de servicio systemd está deshabilitada?

Tengo la siguiente unidad de servicio systemd para configurar los umbrales de batería de mi computadora portátil:

[Unit]
Description=Set Battery Charge Thresholds

[Service]
Type=oneshot
ExecStart=/usr/bin/tpacpi-bat -s --start 1 30
ExecStart=/usr/bin/tpacpi-bat -s --stop 1 85
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Lo que me gustaría es una forma de ejecutar comandos cuando desactivo la unidad de servicio (para poder restablecer convenientemente los umbrales a sus valores predeterminados). es posible?

Respuesta1

Échale un vistazo ExecStopoExecStopPost

Parada ejecutiva

Comandos a ejecutar para detener el servicio iniciado mediante ExecStart=. Este argumento requiere varias líneas de comando, siguiendo el mismo esquema descrito anteriormente para ExecStart=. El uso de esta configuración es opcional. Después de ejecutar los comandos configurados en esta opción, todos los procesos restantes para un servicio finalizan de acuerdo con la configuración KillMode= (consulte systemd.kill(5)). Si no se especifica esta opción, el proceso finaliza enviando la señal especificada en KillSignal= cuando se solicita la parada del servicio. Se admite la sustitución de variables de entorno y especificadores (incluido $MAINPID, ver arriba).

...

Se recomienda utilizar esta configuración para comandos que se comunican con el servicio solicitando una terminación limpia. Cuando se ejecutan los comandos especificados con esta opción, se debe asumir que el servicio aún está completamente activo y puede reaccionar correctamente a todos los comandos. Para los pasos de limpieza post-mortem, utilice ExecStopPost= en su lugar.

ExecStopPost

Comandos adicionales que se ejecutan después de detener el servicio. Esto incluye casos en los que se utilizaron los comandos configurados en ExecStop=, en los que el servicio no tiene ningún ExecStop= definido o en los que el servicio se cerró inesperadamente. Este argumento requiere varias líneas de comando, siguiendo el mismo esquema descrito para ExecStart=. El uso de estas configuraciones es opcional. Se admite la sustitución de variables de entorno y especificadores. Tenga en cuenta que, a diferencia de ExecStop=, los comandos especificados con esta configuración se invocan cuando un servicio no se inicia correctamente y se cierra nuevamente.

Se recomienda utilizar esta configuración para operaciones de limpieza que se ejecutarán incluso cuando el servicio no se haya iniciado correctamente. Los comandos configurados con esta configuración deben poder funcionar incluso si el servicio no se inició a mitad de camino y dejó datos inicializados de forma incompleta. Como los procesos del servicio ya han finalizado cuando se ejecutan los comandos especificados con esta configuración, no deben intentar comunicarse con ellos.

Tenga en cuenta que todos los comandos que están configurados con esta configuración se invocan con el código de resultado del servicio, así como el código de salida y el estado del proceso principal, establecidos en las variables de entorno $SERVICE_RESULT, $EXIT_CODE y $EXIT_STATUS, consulte systemd.exec (5) para más detalles.

Ambos se pueden utilizar para ejecutar comandos cuando el servicio está detenido.

Las principales diferencias entre los dos:

  • ExecStopse ejecuta mientras el proceso principal aún se está ejecutando y solo se ejecutará cuando el servicio se detenga después de ejecutarse normalmente (lo que significa que todos los servicios ExecStartdeben ExecStartPretener éxito y cualquiera Conditions... también debe pasar).

  • ExecStopPostse ejecuta incluso si el "servicio se cerró inesperadamente", lo que cubre fallas. La mayor ventaja de esto es cuando tienes varios ExecStarts, si uno de ellos tiene éxito y el otro falla, ExecStopPostpuedes usarlo para intentar limpiar el éxito parcial.

información relacionada