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

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

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

Eu tentei usar kill, skille pkillcom diferentes opções e -9sinais, mas sem sucesso.

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

Existe outro caminho?

Editar:

ps -o pid, ppid, stat, comunicação

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 a parte superior mostram que o processo zumbi está usando recursos:

Edit 2: Acho que encontrei algo. Eu tentei sair e vi esta mensagem:

O problema é que, quando você instala uma partição de disco rígido externo, você pode usar o ubuntu 10.04 em partições ext4, o que significa que você pode usar o seguinte comando:

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

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

kill, skill pkillnão funcionará porque o processo já foi encerrado, apenas que sua entrada não foi removida.

O processo de zumbi pode ser morto enviando um SIGCHLDsinal para o pai. Eu acho que o número do sinal de SIGCHLDé 17ou18

Se isso também falhar, convém matar o próprio pai.

Da Wikipedia no sinal SIGCHLD:

Quando um processo filho termina antes que o pai chame a espera, o kernel retém algumas informações sobre o processo para permitir que o pai chame a espera mais tarde. Como a criança ainda está consumindo recursos do sistema, mas não executando, é conhecido como um processo zumbi.

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 - ciclo de memória ou CPU, adicione uma explicação. AFAIK dificilmente ocupa recursos significativos do sistema.

EDIT 2: Citando da Wikipedia

Nos sistemas operacionais Unix e Unix-like, um processo zumbi ou um processo extinto é um processo que concluiu a execução, mas ainda possui uma entrada na tabela de processos. Essa entrada ainda é necessária para permitir que o processo que iniciou o processo (agora zumbi) leia seu status de saída.

Portanto, a entrada é mantida para que o processo pai possa conhecer 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, nunca experimentei um processo zumbi usando 100% da CPU. Vendo isso pela primeira vez.

Tente fazer um killall utorrent.exe

Eu posso ver que existem duas instâncias utorrent.exee uma delas é zumbi. Provavelmente o segundo (filho). killall deve matar o pai, já 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.

Tente killall --signal=KILL utorrent.exe

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

Obter a lista de PID do processo utorrent.exe

ps -e grep -i utorrent

Você deve obter 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 aaaa

EDIT 5

Tente encontrar o ID pai 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. O ID do processo 1pertence ao init sem o qual seu sistema não pode executar

Usar killo próprio processo é realmente ineficaz, pois o processo já está morto; killtraz um processo ao vivo para o estado de zumbi.

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

Matar o pai do processo zumbi geralmente é eficaz porque o processo zumbi volta a initser pai assim que o processo pai termina (por exemplo, matar o pai transformou esse processo em um zumbi e o avô leu o código de saída do pai) , para que o pai realmente se foi). Um zumbi pode ser pai de um zumbi; portanto, apenas matar o pai não é suficiente, ele também precisa ser coletado por outro processo.

Observe que os processos nunca são responsáveis ​​pela limpeza de seus netos - eles sempre revertem para o processo 1 como pai (é por isso que os autores de daemon às vezes usam um garfo duplo () e encerram o processo no meio para desassociar totalmente o processo filho da chamada. Concha)

A razão pela qual matar wineprovavelmente não é eficaz é porque não era realmente o pai do processo de zumbi; pelo contrário, o "utorrent.exe", descendente direto do init, é. No entanto, esse processo ainda está em execução normalmente, apenas negligenciando suas funções.

Maneira muito mais fácil do que killall, -9, etc:

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

2) Se você estiver usando o 11.04 ou superior, 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 será eliminado por você.

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

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

wineserver -kentão eu mataria o "Filho do processo" killall -9 Oblivion.exe(por exemplo)

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

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

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

Com um disco rígido normal, o disco é o gargalo e você não notará um problema de desempenho no restante da á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. Essa tem sido minha experiência desde a mudança para um SSD.

No que diz respeito aos processos de extermínio, outros forneceram melhores conselhos do que eu - o uso do sinal KILL geralmente funciona, mas tive o estranho que exigiu uma reinicialização ao longo dos anos.