Existe alguma maneira de matar um processo de zumbis sem reiniciar?

Question

Existe alguma maneira de matar um processo zumbi sem reiniciar? Aqui está como isso aconteceu:

Eu quero baixar um arquivo de 12GB usando torrent. Depois de adicionar o arquivo .torrent, a transmissão se transformou em um processo zumbi (eu tentei o ktorrent também. O mesmo comportamento). Finalmente eu poderia baixar o arquivo usando o µTorrent, mas depois de fechar o programa, ele se transforma em um zumbi também.

Eu tentei usar kill , skill e pkill com opções diferentes e -9 sinal mas sem sucesso.

Depois de ler algumas soluções na web, descobri que matar o pai pode matar o zumbi. Mas matar vinho também não ajudou.

Existe outro jeito?

Editar:

ps -o pid, ppid, stat, comm

PID  PPID STAT COMMAND
7121  2692 Ss   bash
7317  7121 R+   ps

saída pstree:

init─┬─GoogleTalkPlugi───4*[{GoogleTalkPlug}]
 ├─NetworkManager─┬─dhclient
 │                └─{NetworkManager}
 ├─acpid
 ├─amarok───19*[{amarok}]
 ├─apache2───5*[apache2]
 ├─atd
 ├─avahi-daemon───avahi-daemon
 ├─bonobo-activati───{bonobo-activat}
 ├─clock-applet
 ├─console-kit-dae───63*[{console-kit-da}]
 ├─cron
 ├─cupsd
 ├─2*[dbus-daemon]
 ├─2*[dbus-launch]
 ├─desktopcouch-se───desktopcouch-se
 ├─firefox───run-mozilla.sh───firefox-bin─┬─plugin-containe───8*[{plugin-contain}]
 │                                        └─14*[{firefox-bin}]
 ├─gconfd-2
 ├─gdm-binary─┬─gdm-simple-slav─┬─Xorg
 │            │                 ├─gdm-session-wor─┬─gnome-session─┬─bluetooth-apple
 │            │                 │                 │               ├─compiz───sh───gtk-window-deco
 │            │                 │                 │               ├─fusion-icon
 │            │                 │                 │               ├─gdu-notificatio
 │            │                 │                 │               ├─gnome-panel───{gnome-panel}
 │            │                 │                 │               ├─gnome-power-man
 │            │                 │                 │               ├─gpg-agent
 │            │                 │                 │               ├─gwibber-service
 │            │                 │                 │               ├─nautilus
 │            │                 │                 │               ├─nm-applet
 │            │                 │                 │               ├─polkit-gnome-au
 │            │                 │                 │               ├─2*[python]
 │            │                 │                 │               ├─qstardict───{qstardict}
 │            │                 │                 │               ├─ssh-agent
 │            │                 │                 │               ├─tracker-applet
 │            │                 │                 │               ├─trackerd
 │            │                 │                 │               ├─wakoopa─┬─wakoopa
 │            │                 │                 │               │         └─3*[{wakoopa}]
 │            │                 │                 │               └─{gnome-session}
 │            │                 │                 └─{gdm-session-wo}
 │            │                 └─{gdm-simple-sla}
 │            └─{gdm-binary}
 ├─6*[getty]
 ├─gnome-keyring-d───2*[{gnome-keyring-}]
 ├─gnome-screensav
 ├─gnome-settings-
 ├─gnome-system-mo
 ├─gnome-terminal─┬─bash───ssh
 │                ├─bash───pstree
 │                ├─gnome-pty-helpe
 │                └─{gnome-terminal}
 ├─gvfs-afc-volume───{gvfs-afc-volum}
 ├─gvfs-fuse-daemo───3*[{gvfs-fuse-daem}]
 ├─gvfs-gdu-volume
 ├─gvfsd
 ├─gvfsd-burn
 ├─gvfsd-computer
 ├─gvfsd-metadata
 ├─gvfsd-trash
 ├─hald─┬─hald-runner─┬─hald-addon-acpi
 │      │             ├─hald-addon-cpuf
 │      │             ├─hald-addon-inpu
 │      │             └─hald-addon-stor
 │      └─{hald}
 ├─indicator-apple
 ├─indicator-me-se
 ├─indicator-sessi
 ├─irqbalance
 ├─kded4
 ├─kdeinit4─┬─kio_http_cache_
 │          └─klauncher
 ├─kglobalaccel
 ├─modem-manager
 ├─multiload-apple
 ├─mysqld───10*[{mysqld}]
 ├─named───10*[{named}]
 ├─nmbd
 ├─notification-ar
 ├─notify-osd
 ├─polkitd
 ├─pulseaudio─┬─gconf-helper
 │            └─2*[{pulseaudio}]
 ├─rsyslogd───2*[{rsyslogd}]
 ├─rtkit-daemon───2*[{rtkit-daemon}]
 ├─smbd───smbd
 ├─snmpd
 ├─sshd
 ├─timidity
 ├─trashapplet
 ├─udevd───2*[udevd]
 ├─udisks-daemon─┬─udisks-daemon
 │               └─{udisks-daemon}
 ├─upowerd
 ├─upstart-udev-br
 ├─utorrent.exe───{utorrent.exe}
 ├─vnstatd
 ├─winbindd───2*[winbindd]
 ├─wnck-applet
 ├─wpa_supplicant
 └─xinetd

O monitor do sistema e o topo mostram que o processo zumbi está usando recursos:

Editar 2: Eu acho que encontrei algo. Eu tentei sair e vi esta mensagem:

Como outros clientes de torrent têm o mesmo problema, talvez seja algo sobre o tamanho do arquivo. Estou usando o Ubuntu 10.04 em partições ext4. Matar o nautilus e enviar sinal SIGCHLD para ele não funcionou.

    

Answer 1

Eu não acho que o processo zumbi é uma grande dor de cabeça. Um processo zumbi não ocupa nenhum recurso. É só que tem sua entrada na tabela de processos.

Um processo de zumbis não é um processo órfão, ele tem um pai.

kill , skill pkill não funcionará, pois o processo já foi encerrado, apenas que a entrada não foi removida.

O processo de zumbis pode ser eliminado enviando SIGCHLD de sinal para o pai. Eu acho que o número do sinal de SIGCHLD é 17 ou 18

Se isso também falhar, talvez você queira matar o pai em si.

Da Wikipedia no sinal SIGCHLD:

  

Quando um processo filho termina antes   o pai chamou wait, o kernel   retém algumas informações sobre o   processo para permitir que seu pai chame   espere depois. Porque a criança é   ainda consumindo recursos do sistema, mas   não executá-lo é conhecido como um zumbi   processo.

EDIT 1 : Os recursos do sistema consumidos são principalmente a entrada da tabela de processos. Se alguém souber se consome mais do que isso - memória ou ciclo de CPU, adicione uma explicação. AFAIK dificilmente ocupa recursos significativos do sistema.

EDIT 2: Citação da Wikipédia

  

Em computadores Unix e semelhantes a Unix   sistemas operacionais, um processo zumbi ou   processo defunto é um processo que tem   execução concluída, mas ainda tem um   entrada na tabela de processos. Esta entrada   ainda é necessário para permitir o processo   que começou o processo (agora zumbi)   para ler seu status de saída.

Portanto, a entrada é mantida para que o processo pai possa saber o status de saída porque, no momento em que o filho sai, o pai provavelmente não está em um estado ou não está pronto para ler seu status de saída.

EDIT 3

Até a data em que nunca experimentei um processo de zumbi levando 100% da CPU. Vendo isso pela primeira vez.

Tente fazer um killall utorrent.exe

Eu posso ver que há duas instâncias de utorrent.exe e uma delas é zumbi. Provavelmente o segundo (filho). killall deve matar o pai desde que o filho (zumbi) não pode ser morto.

EDIT 4

Parece que o killall não funcionou, pois estava dando sinal TERM em vez de KILL.

Experimente o killall --signal=KILL utorrent.exe

Se isso não funcionar, tente matar o processo seletivamente.

Obtenha a lista do processo PID do utorrent.exe

  

ps -e | grep -i utorrent

Você deve receber dois processos como

xxxx ?        aa:bb:cc utorrent.exe defunct
yyyy ?        aa:bb:cc utorrent.exe

Então o segundo é o pai. Mate-o usando

  

matar -9 yyyy

EDIT 5

Por favor, tente encontrar o Parent Id do processo por este comando bash

  

cat / proc / {defunctpid} / status | grep -i ppid

no seu caso é

  

cat / proc / 7298 / status | grep -i ppid

Se a saída vier como

  

PPid: 1

Então, infelizmente, acho que você está sem sorte. ID do processo 1 pertence ao init sem o qual seu sistema não pode executar

    

Answer 2

Usar kill no processo em si é realmente ineficaz, pois o processo já está morto; kill traz um processo ao vivo para o estado zumbi.

O processo pai é responsável por pegar o código de saída do processo; o processo continua sendo um zumbi até que isso seja feito. O processo init vai pegar o código de saída de qualquer processo e jogá-lo fora, então é o pai do "último recurso" que limpará qualquer zumbi que seja um descendente direto.

Matar o pai do processo zumbi é geralmente eficaz porque o processo zumbi reverte para init como pai assim que o processo pai é eliminado (ou seja, matar o pai transformou esse processo em um zumbi e o avô leu o código de saída do pai, então o pai realmente desapareceu). Um zumbi pode ser pai de um zumbi, então simplesmente matar o pai não é suficiente, ele também precisa ser coletado por outro processo em si.

Observe que os processos nunca são responsáveis pela limpeza de seus netos - eles sempre retornam ao processo 1 como pai (é por isso que os autores de daemon usam um fork duplo () e terminam o processo no meio para desassociar completamente o processo filho da invocação de shell)

A razão pela qual matar wine provavelmente não é eficaz é porque não era realmente o pai do processo zumbi; em vez disso, o "utorrent.exe" que é um descendente direto do init é. Este processo, no entanto, ainda está funcionando normalmente, negligenciando apenas seus deveres.

    

Answer 3

Muito mais fácil que killall, -9, etc:

1) Use o qBitorrent em vez do console uTorrent (também estou esperando por uma versão GUI e qBitorrent é essencialmente isso).

2) Se você estiver usando 11.04 ou acima, pressione alt + f2 (abre uma janela de comandos especiais), digite xkill e seu mouse agora é um x. Clique no programa que você deseja fechar (UI = ID do processo) e ele irá matá-lo para você.

Dica avançada: ligue um atalho de teclado para "xkill" como eu tenho no meu teclado macro G15.

    

Answer 4

No meu caso, quando o vinho trava e eu não posso matar a criança zumbi com uma espingarda que eu faria:

wineserver -k , então eu mataria o "Filho do Processo" killall -9 Oblivion.exe (Por exemplo)

Para o que eu entendo, o servidor de vinhos envia um sinal para todos os seus filhos zumbis que todos eles vão morrer (por causa da espingarda que você conhece), mas às vezes uma criança pensa sozinha e quer tomar o mundo pela tempestade. Então eu faço o adicional killall -9 ou o kill -9 com o id do processo.

    

Answer 5

Meu palpite é que você está usando um SSD.

Ao adicionar grandes torrents a um cliente torrent, os arquivos "placeholder" do torrent que você está baixando são realmente criados no disco, mas estão vazios até serem gradualmente preenchidos durante o processo de download.

Com um disco rígido normal, o disco é o gargalo e você não notará um problema de desempenho com o restante da sua área de trabalho.

No entanto, ao usar um SSD, a CPU é o gargalo e o aplicativo parece ter travado (fica cinza). Se você deixar por um tempo, ele se recuperará e tudo ficará bem. Esta tem sido minha experiência desde que mudei para um SSD.

No que diz respeito aos processos de matança, outros forneceram conselhos melhores do que eu - usar o sinal KILL geralmente funciona, mas eu tive o estranho que exigiu um reinício ao longo dos anos.