O que exatamente é "um trabalho de parada", como em "Um trabalho de parada está em execução ..."?


29

Depois que um comando de desligamento é emitido, algumas vezes é exibida uma mensagem de status como esta:

A stop job is running for Session 1 of user xy

e, em seguida, o sistema trava por algum tempo, ou para sempre, dependendo ??

Então, o que exatamente é "um trabalho temporário"?

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


11
Talvez deva ser interrompido o trabalho? A sessão interrompeu os trabalhos, que na verdade não estão em execução e, portanto, não têm a oportunidade de responder aos sinais de finalização.
Kaz

Respostas:


27

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


11
De acordo com esta resposta, unix.stackexchange.com/a/297318/224025 , podemos mudar dessa vez. Seria seguro (ou faria algum mal) se eu o alterar para zero segundos?
GypsyCosmonaut

11
Na verdade, o parágrafo final desta resposta e o manual do usuário que eu indico para uma leitura mais aprofundada informam sobre a alteração do tempo limite. Uma pergunta sobre o que significa um tempo limite de 0 e é seguro empregar deve ser feita como uma pergunta em Como perguntar, porque é uma pergunta subsequente de uma pergunta sobre o que é um "trabalho interrompido" e por que os tempos limites variam. Suspeito que possa ser uma boa.
23417 JdeBP

2

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

Quando um trabalho está sendo interrompido, como em systemctl stop ...uma pergunta, é quanto tempo aguardar a conclusão do trabalho antes de declarar falha e interromper os processos do trabalho com o SIGKILLsinal. Realmente não queremos usar a SIGKILLmenos que seja necessário, pois isso não dá a oportunidade para o processo sair corretamente. Para alguns processos, alguns segundos podem levar tempo suficiente para declarar falha, para outros processos, como um banco de dados, pode haver E / S de rede e disco substanciais para que o trabalho seja interrompido de maneira limpa e, portanto, podemos dar a essas unidades vários minutos para desligar corretamente .

O que você vê no desligamento é o equivalente a systemctl stop $UNIT_NAMElevar algum tempo para ser executado. Existe um contador que mostra os segundos decorridos e o tempo máximo de espera antes da emissão do SIGKILL e o desligamento continua independentemente.

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


"Systemd usa" unit "e" job "para significar praticamente a mesma coisa." Eu não acho que isso seja verdade: grosso modo, um "trabalho" é um pedido para fazer algo a uma "unidade". Veja a resposta do @ JdeBP para detalhes.
Thomas


0

"Interromper trabalhos" é o momento systemdem que um determinado "trabalho" é interrompido, por exemplo, algum processo que está aguardando para concluir antes de continuar. Se você receber uma mensagem de aviso de que "um trabalho de interrupção está sendo executado ..." (etc), tecnicamente significa que algo está pendente na fila de trabalhos.

No entanto, antes de pesquisar em toda a fila de tarefas do sistema, lembre-se de que algumas vezes essas mensagens de aviso são um resultado indireto de fatores ambientais (na verdade, a mensagem é mencionada no repositório do GitHub como um possível bug).

Por exemplo: estávamos recebendo mensagens relacionadas ao "interromper o trabalho" e não conseguíamos entender o porquê .... Acontece que o disco estava quase sem espaço e começou a fazer o sistema operacional se comportar de maneira estranha.

A atualização do servidor para um disco maior e a reinicialização corrigiram;)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.