Lendo uma entrada de elav. Lembrei que em um fórum alguém pediu ajuda devido ao sistema lento, algumas das soluções focadas em processos.
Os principais estados dos processos no Linux são:
Dormir (S) : Processos que aguardam sua vez de execução.
Correndo (R) : Processos em execução.
Esperando (D) : Processos que aguardam a conclusão de uma operação de entrada / saída.
Zumbi (Z) : Processos que foram finalizados, mas continuam aparecendo na tabela de processos. Eles podem ser causados por erros de programação e podem ser um sintoma de um sistema lento ou causador de problemas.
Um processo zumbi é aquele que nunca recebeu um sinal do processo pai que o criou, um processo filho é aquele que tem sua origem em um processo de nível superior conhecido como processo pai que é responsável por enviar os sinais para os processos filhos gerados por para indicar que seu tempo de vida terminou.
Eles podem ser causados por erros de programação e podem ser um sintoma de um sistema lento ou causador de problemas. Essa situação geralmente ocorre, até porque alguma configuração não foi contemplada pelo desenvolvedor.
Na Wikipedia você pode ler mais sobre esses processos.
Executando o comando top podemos ver em tempo real os processos que estão rodando no sistema, e ele vai indicar se há algum em estado zumbi, mas não indica qual está.
Para ver todos os processos, digite no terminal: ps aux, e para ver apenas os zumbis: ps -el | grep 'Z'o ps -A -ostat, ppid, pid, cmd | grep -e '^ [Zz]'
alf @ Alf ~ $ ps -A -ostat, ppid, pid, cmd | grep -e '^ [Zz]'
Z 1945
Se ao listar os processos aparecer um com status Z, significa que é um zumbi, o que por sua vez significa que o aplicativo não está bem resolvido ou possui bugs, sabendo que seu PID pode ser eliminado executando no terminal um comando semelhante ao , neste exemplo:
alf @ Alf ~ $ kill -9 1945
Quando você tem muitos processos zumbis ou pelo menos mais de um, você pode usar o seguinte comando que os mata, ele só funciona para isso, se você executá-lo sem ter processos zumbis nada acontecerá:
alf @ Alf ~ $ sudo kill -HUP `ps -A -ostat, ppid, pid, cmd | grep -e '^ [Zz]' | awk '{print $ 2}' ''
lembranças
🙁
Obrigado, muito boa contribuição, vou guardar os comandos para fazer verificações periódicas.
Obrigado, bom artigo.
Alguns esclarecimentos sobre o seu artigo:
O termo "processo zumbi" é tecnicamente inadequado e aqueles de nós que têm um pouco de experiência com GNU / Linux devem evitar usá-lo já que não há nenhum processo em execução, mas é apenas uma referência a um processo que não existe mais no sistema e ele não divulgou seu identificador.
Um "processo zumbi" é na verdade a entrada na tabela de mapeamento do identificador do processo (descritor do processo), apenas isso, para não consumir recursos além de alguns bytes de memória que o sistema usa para manter o controle da tabela do processo.
O único problema que pode haver com os descritores de registro fantasma (ou zumbi) é que, se eles gerarem muito rápido, podem teoricamente ocupar toda a tabela de alocação do descritor de processo, deixando o sistema sem espaço para novos registros, portanto, seria potencialmente impossível executar novos programas -que registram seus processos- eventualmente travando a máquina.
No entanto, isso é quase impossível de acontecer, pois em sistemas de 32 bits existem 32767 espaços para registrar processos (raramente ou nunca usados) e o dobro disso em um sistema de 64 bits.
A única maneira de fazer um sistema travar com processos mortos mal removidos é criar os processos e eliminá-los rapidamente sem limpar adequadamente o descritor do processo (ou seja, criar "processos zumbis"), mas, vamos enfrentá-lo, se alguém quiser travar um sistema existem maneiras muito mais diretas do que isso. para começar a criar novos processos rapidamente de forma exponencial que congestionam o sistema e o travam; uma das maneiras de conseguir isso com uma bomba de garfo:
: () {: |: &};:
Você pode tornar o sistema relativamente resistente a uma fork bomb configurando corretamente o /etc/security/limits.conf, mas deve-se levar em consideração que quanto mais limitarmos a possibilidade de criar novos processos, seremos capazes de executar menos aplicativos simultaneamente em nosso sistema. No entanto, é uma ferramenta válida para todos os administradores de sistemas paranóicos que desejam ter um controle muito preciso sobre seus sistemas!
Este artigo contém boas informações sobre descritores de processo inválidos:
http://www.howtogeek.com/119815/htg-explains-what-is-a-zombie-process-on-linux/
E nisso há uma explicação clara sobre como funciona uma bomba fork: http://stackoverflow.com/questions/991142/how-does-this-bash-fork-bomb-work
Salu2
msx: «O termo“ processo zumbi ”é tecnicamente inapropriado e aqueles de nós que têm um pouco de experiência com GNU / Linux devem evitar usá-lo…» Ha ha ha. Só existe algo maior do que o seu orgulho: o seu mau gosto. Ei, o que você fez é de mau gosto, se você quer dar uma palestra, conseguir uma na faculdade, ou colocar seu próprio blog e escrever o que quiser, mas vir aqui corrigir o flat para bom Alf é mesmo de mau gosto .
A verdade me pareceu um comentário bastante interessante. Muito mais que a postagem
obrigado muito interessante.
excelente artigo obrigado
msx
«O termo“ processo Zombie ”é tecnicamente impróprio e aqueles de nós que têm alguma experiência em GNU / Linux devem evitar usá-lo»
Teremos que avisar os desenvolvedores, pois como você verá, o termo zumbi também é usado, aí eu li no console.
lembranças
Parabéns, artigo muito bom, sempre tive dúvidas que fossem os PZs mas nunca tive tempo de investigar, agora entro na página e encontro a resposta, obrigado…
No KDE com controle + fuga, as atividades do sistema são interrompidas e podemos matar esses zumbis rapidamente.
Uma correção, é um ZOMBIE, não um processo ZOMBIE
Zombie está em inglês
Zumbi em espanhol
Luxo, obrigado!
Primeiro, o termo processo zumbi parece totalmente correto. Além disso, o termo é o menos importante.
A questão é que, como indica o msx, e na mesma wikipedia (li o artigo), o processo zumbi está realmente morto.
«Quando um processo termina, toda a sua memória e recursos associados são desreferenciados, para que possam ser utilizados por outros processos. De qualquer forma, a entrada do processo na tabela de processos ainda permanece »
Ou seja, o processo não está mais consumindo recursos do sistema, portanto, a carga no sistema é mínima, conforme explicado por msx.
Porém, a única coisa que tem é uma entrada inválida na tabela de processos ... que, se houver milhares delas, talvez seja uma carga (afinal, o processador tem que ler a tabela de processos e lerá um muitas informações inúteis) além de refletir más práticas de programação (alguém está fazendo aplicativos mal feitos).
Mas por si só a explicação do post não é tão correta e a correta seria a fornecida pelo msx.