Después de emitir un comando de apagado, a veces uno recibe un mensaje de estado como este:
A stop job is running for Session 1 of user xy
y luego el sistema se cuelga por un tiempo, o para siempre dependiendo de ???
Entonces, ¿qué es exactamente "dejar de trabajar"?
Además, ¿por qué a veces estima el tiempo que tardará con bastante precisión y otras veces puede ejecutarse eternamente?
Respuesta aceptada:
systemd opera internamente en términos de una cola de "trabajos". Cada trabajo (simplificando un poco) es una acción a realizar:detener, verificar, iniciar o reiniciar una unidad en particular .
Cuando (por ejemplo) le indica a systemd que inicie una unidad de servicio , elabora una lista de trabajos de parada e inicio para cualquier unidad (unidades de servicio, unidades de montaje, unidades de dispositivo, etc.) que sean necesarias para lograr ese objetivo, de acuerdo con los requisitos y dependencias de la unidad, las ordena, de acuerdo con las relaciones de orden de la unidad , resuelve y (si es posible) corrige cualquier autocontradicción y (si el paso final tiene éxito) los coloca en la cola.
Luego intenta realizar los "trabajos" en cola.
Se está ejecutando un trabajo detenido para la Sesión 1 del usuario xy
La unidad nombre para mostrar aquí está Session 1 of user xy . Esta será (por el nombre para mostrar) una sesión unidad, no un servicio unidad. Esta es la abstracción de la sesión de inicio de sesión del espacio de usuario que mantiene logind de systemd programa y sus complementos PAM. Es (en esencia y en teoría) una agrupación de todos los procesos que ese usuario está ejecutando como una "sesión de inicio de sesión" en algún lugar.
El trabajo que se ha puesto en cola es stop . Y probablemente lleve mucho tiempo porque la gente de systemd ha combinado erróneamente la sesión colgar con sesión cerrar . Rompen el primero para que el segundo funcione y, en respuesta, algunas personas modifican systemd para romper el segundo y hacer que el primero funcione. La gente de systemd realmente debería reconocer que son dos cosas diferentes.
En su sesión de inicio de sesión, tiene algo que ignora SIGTERM o que tarda mucho en terminar una vez que ha visto SIGTERM . Irónicamente, lo primero es el comportamiento de larga data de algunos caparazones de control de trabajo. La forma correcta de finalizar los líderes de sesión de inicio de sesión cuando son estos shells de control de trabajo en particular es decirles que la sesión ha sido colgada , tras lo cual rescinden todos sus sus trabajos (un tipo de trabajo diferente al trabajo systemd interno) y luego se terminan.
Lo que realmente sucede es que systemd está esperando el tiempo de espera de detención de la unidad. hasta que recurre a SIGKILL . Este tiempo de espera se puede configurar por unidad, por supuesto, y se puede configurar para que nunca se agote. De ahí que uno pueda ver potencialmente diferentes comportamientos.
Lecturas adicionales
- Lennart Poettering (2015). systemd. páginas del manual systemd. Freedesktop.org.
- Jonathan de Boyne Pollard (2016-06-01). systemd elimina los procesos en segundo plano después de que el usuario cierra la sesión . 825394. Rastreador de errores de Debian.
- Lennart Poettering (2015). systemd.matar. páginas del manual systemd. Freedesktop.org.
- Lennart Poettering (2015). systemd.servicio. páginas del manual systemd. Freedesktop.org.
- ¿Por qué bash ignora SIGTERM?
- https://superusuario.com/questions/1102242/