O que exatamente é “um trabalho de parada”, como em “Um trabalho de parada está em execução…”?

19

Depois que um comando de desligamento é emitido, às vezes um recebe uma mensagem de status assim:

A stop job is running for Session 1 of user xy

e depois o sistema trava por algum tempo, ou para sempre, dependendo de ???

Então, o que exatamente é "um trabalho de parada"?

Além disso, por que às vezes estima o tempo que levará, com bastante precisão, e outras vezes pode durar para sempre?

    
por Eliptical view 19.09.2016 / 01:57

3 respostas

17

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 até que ele recorra a 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

por 19.09.2016 / 10:09
2

Essas mensagens são do systemd, que é um sistema init que inicia e interrompe tarefas. Jobs podem ser daemons, mas também podem realizar pequenas tarefas, como montar e desmontar discos, excluir / tmp ou salvar e restaurar o brilho da tela durante a inicialização. systemctl list-units lhe dá a ideia. O Systemd usa "unit" e "job" para significar a mesma coisa.

Quando um trabalho está sendo interrompido, como acontece com systemctl stop ... , uma pergunta é por quanto tempo esperar que o trabalho seja concluído antes de declarar a falha e matar os processos do trabalho com o sinal SIGKILL . Nós realmente não queremos usar SIGKILL a menos que tenhamos que, pois não dá a oportunidade para o processo sair de forma limpa. Para alguns processos, alguns segundos podem ter tempo suficiente para declarar falhas; para outros processos, como um banco de dados, pode haver E / S de rede e disco substanciais para que o trabalho pare de forma limpa e, portanto, podemos dar a essas unidades vários minutos para serem encerradas .

O que você está vendo no desligamento é o equivalente a systemctl stop $UNIT_NAME , o que leva algum tempo para ser executado. Há um contador que mostra os segundos decorridos e o tempo máximo de espera antes que o SIGKILL seja emitido e o desligamento continue, independentemente disso.

A menos que haja boas razões para esperar um longo atraso, isso geralmente indica algum tipo de defeito. Isso pode variar de um servidor DHCP que não está respondendo a uma Liberação e, portanto, a ação Liberar precisando expirar ou de algum erro que faz com que um daemon nunca saia.

    
por 19.09.2016 / 09:37
1

Algum serviço está emperrado e o systemd está esperando que ele saia. O Systemd provavelmente não está estimando com precisão o tempo que levará, o tempo (normalmente 90 segundos) é quanto tempo o sistema irá esperar antes de ficar sem paciência. Veja este post:

Um trabalho de parada está sendo executado para a sessão c2 do usuário

    
por 19.09.2016 / 09:33