O systemd opera internamente em termos de uma fila de "jobs". Cada trabalho (simplificando um pouco) é uma ação a ser tomada: parar, verificar, iniciar ou reiniciar uma determinada unidade .
Quando (por exemplo) você instrui o systemd a iniciar uma unidade de serviço , ele elabora uma lista de tarefas de parada e início para qualquer unidade (unidade de serviço, unidade de montagem, unidade de dispositivo e assim por diante) ) são necessários para atingir esse objetivo, de acordo com os requisitos e dependências da unidade, ordena-os, de acordo com as relações de ordenação de unidades, elabora e (se possível) corrige quaisquer contradições, e (se essa última etapa for bem-sucedida) os coloca a fila.
Em seguida, ele tenta executar os "jobs" enfileirados.
A stop job is running for Session 1 of user xy
A unidade nome de exibição aqui é Session 1 of user xy
. Este será (a partir do nome de exibição) uma unidade sessão , não uma unidade serviço . Essa é a abstração de sessão de login do espaço do usuário que é mantida pelo programa logind
do systemd e seus plug-ins 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 é stop
. E provavelmente está demorando muito, porque as pessoas do systemd têm sessões erroneamente confundidas hangup com a sessão shutdown . Eles quebram o primeiro para fazer o segundo funcionar e, em resposta, algumas pessoas alteram o sistema para interromper o último para que o primeiro funcione. As pessoas do sistema devem realmente reconhecer que são duas coisas diferentes.
Na sua sessão de login, você tem algo que ignora SIGTERM
ou que leva muito tempo para ser encerrado depois de ter visto SIGTERM
. Ironicamente, o primeiro é o comportamento de longa data de algumas cápsulas de controle de emprego. A maneira correta de finalizar os líderes de sessão de login quando eles são esses shells de controle de trabalho é dizer a eles que a sessão foi desligada , onde eles terminam todos os trabalhos deles (um tipo diferente de trabalho para o trabalho systemd interno) e, em seguida, encerrar-se.
O que está realmente acontecendo é que o systemd está aguardando o tempo limite de parada SIGKILL
. Esse tempo limite é configurável por unidade, é claro, e pode ser definido para nunca expirar. Por isso, é possível ver comportamentos diferentes.
Leitura adicional
- Lennart Poettering (2015). systemd . páginas de manual do systemd. Freedesktop.org.
- Jonathan de Boyne Pollard (2016-06-01). systemd mata processos em segundo plano depois que o usuário efetua logout . 825394. Rastreador de bugs do Debian.
- Lennart Poettering (2015). systemd.kill . páginas de manual do systemd. Freedesktop.org.
- Lennart Poettering (2015). systemd.service . páginas de manual do systemd. Freedesktop.org.
- Por que o bash ignora o SIGTERM?
- link