Como parar um processo de execução infinito (ztail) iniciado por uma sessão ssh após essa sessão ser fechada

2

Eu tenho um problema peculiar. Meu servidor suporta várias sessões ssh simultaneamente, para que vários administradores possam gerenciar (via interface de linha de comando) simultaneamente. Temos um comando que chama ztail para mostrar os arquivos de log compactados. Agora, quando a sessão ssh atual é fechada (sem pressionar Ctrl - C , para parar o comando ztail ), este comando deve, idealmente, parar de funcionar. Mas o que eu observei quando iniciei uma nova sessão ssh é que o processo ( ztail ) ainda está rodando em background e consumindo minha CPU, mesmo que a sessão anterior tenha sido fechada. Agora, como posso saber quando a sessão foi encerrada, para que eu possa usar essa variável / sinalizador para fechar / interromper qualquer comando iniciado por essa sessão anteriormente fechada?

    
por sanath 11.11.2012 / 07:01

2 respostas

1

Isso só acontece se você executar ztail (ou qualquer outro comando) como um novo processo de nível de raiz (ou seja, sem um processo pai), por exemplo em segundo plano ou via cron.

Geralmente, quando você inicia uma sessão ssh padrão, obtém um processo de shell, que é o processo raiz de todos os programas iniciados. Se a sessão ssh terminar, o kernel elimina todos os processos filhos também. (É por isso que as pessoas geralmente usam screen ou coisas semelhantes para manter as sessões.)

Portanto, a coisa mais fácil para você seria utilizar esse comportamento padrão. Dê uma olhada em ps axjf para verificar qual é o processo raiz de ztail e, em seguida, descubra por que ela sobrevive à sessão ssh terminada.

    
por 11.11.2012 / 19:16
0

Durante a sessão ssh, uma sessão de shell será um processo filho. Esse processo filho terá outro processo filho: ztail . Depois de fechar o ztail shell vai perder seus pais. Como em todos esses processos, eles serão adotados pelo init com PID 1.

Se o pai-pid de ztail for 1, provavelmente é um dos seus "zumbis".

    
por 11.11.2012 / 22:35