O systemd opera internamente em termos de uma fila de "trabalhos". Cada trabalho (simplificando um pouco) é uma ação a ser executada: parar, verificar, iniciar ou reiniciar uma unidade específica .
Quando (por exemplo) você instrui o systemd a iniciar uma unidade de serviço , ele elabora uma lista de parar e iniciar trabalhos para quaisquer unidades (unidades de serviço, unidades de montagem, unidades de dispositivos etc.) necessárias para atingir esse objetivo, de acordo com os requisitos e dependências da unidade, os ordena, de acordo com os relacionamentos de pedidos da unidade, elabora e (se possível) corrige quaisquer autocontradições e (se a etapa final for bem-sucedida) os coloca na fila.
Em seguida, ele tenta executar os "trabalhos" enfileirados.
Um trabalho de parada está em execução para a Sessão 1 do usuário xy
O nome de exibição da unidade aqui é Session 1 of user xy. Esta será (a partir do nome de exibição) uma unidade de sessão , não uma unidade de serviço . Essa é a abstração da sessão de login no espaço do usuário que é mantida pelo logindprograma do systemd e seus plugins PAM. É (em essência e em teoria) um agrupamento de todos os processos que esse usuário está executando como uma "sessão de login" em algum lugar.
O trabalho que foi enfileirado contra ele é stop. E é provavelmente a demorar muito tempo porque as pessoas Systemd erroneamente confundida sessão hangup com sessão de encerramento . Eles quebram o primeiro para fazê-lo funcionar e, em resposta, algumas pessoas alteram o sistema para quebrá-lo e fazê-lo funcionar. As pessoas do sistema realmente deveriam reconhecer que são duas coisas diferentes.
Na sua sessão de login, você tem algo que ignora SIGTERMou que demora muito para terminar, uma vez que foi visto SIGTERM. Ironicamente, o primeiro é o comportamento de longa data de alguns reservatórios de controle de tarefas. A maneira correta de encerrar líderes sessão de login quando estão essas conchas de controlo das tarefas particulares é dizer-lhes que a sessão tenha sido desligou , depois do que eles terminar todas as suas tarefas (um tipo diferente de trabalho para o trabalho systemd interna) e, em seguida, terminam eles mesmos.
O que realmente está acontecendo é que o systemd está aguardando o tempo limite da unidade parar até que recorra SIGKILL. Esse tempo limite é configurável por unidade, é claro, e pode ser definido para nunca atingir o tempo limite. Por isso, é possível ver comportamentos diferentes.
Leitura adicional