systemd opera internamente en términos de una cola de "trabajos". Cada trabajo (simplificando un poco) es una acción a tomar: 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 detención e inicio para cualquier unidad (unidades de servicio, unidades de montaje, unidades de dispositivo, etc.) necesarias para lograr ese objetivo, de acuerdo con los requisitos y dependencias de la unidad, los ordena, de acuerdo con las relaciones de orden de la unidad, funciona y (si es posible) corrige cualquier contradicción, y (si ese paso final es exitoso) los coloca en la cola.
Luego intenta realizar los "trabajos" en cola.
Se está ejecutando un trabajo de detención para la sesión 1 del usuario xy
El nombre para mostrar de la unidad aquí es Session 1 of user xy. Esta será (desde el nombre para mostrar) una unidad de sesión , no una unidad de servicio . Esta es la abstracción de sesión de inicio de sesión de espacio de usuario que mantiene el logindprograma systemd 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 alguna parte.
El trabajo que se ha puesto en cola contra él es stop. Y es probable que tomar mucho tiempo porque la gente systemd han fusionado erróneamente sesión de colgar con la sesión de cierre . Rompen el primero para que el último funcione, y en respuesta algunas personas alteran el sistema para romper el último y hacer que el primero funcione. La gente del sistema realmente debería reconocer que son dos cosas diferentes.
En su sesión de inicio de sesión, tiene algo que ignora SIGTERMo que tarda mucho en terminar una vez que lo ha visto SIGTERM. Irónicamente, el primero es el comportamiento de larga data de algunos proyectiles de control de trabajo. La forma correcta de terminar 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 se ha colgado , con lo cual terminan todos sus trabajos (un tipo diferente de trabajo para el trabajo interno del sistema) y luego terminar ellos mismos.
Lo que está sucediendo realmente es que systemd está a la espera de la unidad parada de tiempo de espera hasta que se recurre a SIGKILL. Este tiempo de espera es configurable por unidad, por supuesto, y se puede configurar para que nunca se agote el tiempo de espera. Por eso, uno puede ver diferentes comportamientos.
Otras lecturas