Como posso matar o meu processo sim com backticked?

4

Eu estava brincando no meu terminal, que executa zsh . Eu digitei o seguinte:

$ '
bquote> yes
bquote> '

E então, yes começou a ser executado em segundo plano, eu acho. Nem Ctrl + C nem Ctrl + \ funcionaram para eliminar o processo. Fechei o terminal, mas o processo parece continuar. Tudo o que posso dizer é que posso confirmar que meu fã ainda funciona.

Eu executei os seguintes comandos, que também não funcionam:

  • pkill yes
  • pkill yes\ \<defunct\> (apareceu ao usar a conclusão da Tab )
  • killall -9 yes
  • pkill zsh
  • killall -9 zsh

Não consigo reiniciar o computador porque há um arquivo grande sendo copiado para outro computador e não quero reiniciar esse processo.

Aqui está minha top output:

top - 16:06:16 up  7:41,  3 users,  load average: 1,49, 1,33, 1,02
Tasks: 305 total,   3 running, 301 sleeping,   0 stopped,   1 zombie
%Cpu(s): 53,8 us,  2,5 sy,  0,0 ni, 43,5 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
KiB Mem:   6009896 total,  5897432 used,   112464 free,    17152 buffers
KiB Swap:  7811068 total,      280 used,  7810788 free.  2225944 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
24814 john      20   0 2367448 2,219g   3896 R  98,9 38,7  12:29.00 zsh         
 2134 john      20   0 1576256 117104  69868 S   2,7  1,9   2:44.03 compiz      
 1163 root      20   0  311032  66020  25016 S   2,3  1,1   9:28.03 Xorg        
25428 john      20   0   30220   3800   3008 S   2,0  0,1   0:08.48 htop        
  408 root     -51   0       0      0      0 S   1,3  0,0   4:25.59 irq/32-iwl+ 
25359 john      20   0  581928  31888  25080 S   1,3  0,5   0:00.92 gnome-term+ 
 2051 john      20   0  653056  32296  23640 S   1,0  0,5   0:05.72 unity-pane+ 
25479 john      20   0   29276   3164   2544 R   0,7  0,1   0:00.04 top         
  819 message+  20   0   40748   4044   2372 S   0,3  0,1   0:04.27 dbus-daemon 
 1995 john      20   0  363388  10984   5828 S   0,3  0,2   0:20.36 ibus-daemon 
 2049 john      20   0   39252   3544   3016 S   0,3  0,1   0:00.27 dbus-daemon 
 2103 john      20   0  205408   6516   5936 S   0,3  0,1   0:05.65 ibus-engin+ 
 2157 john      20   0  551436  10652   8376 S   0,3  0,2   0:01.35 indicator-+ 
24009 nobody    20   0  275852  14904  12260 S   0,3  0,2   0:23.73 smbd        
24536 root      20   0       0      0      0 S   0,3  0,0   0:00.33 kworker/u8+ 
    1 root      20   0   33888   4452   2720 S   0,0  0,1   0:01.67 init        
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd    

Aqui está minha ps aux | grep yes output:

$ ps aux | grep yes
john     25004  0.1  0.0      0     0 ?        Z    15:53   0:01 [yes] <defunct>
john     25603  0.0  0.0  15976  2220 pts/25   S+   16:13   0:00 grep --color=auto yes
    
por Exeleration-G 06.01.2016 / 16:08

2 respostas

4

Esta resposta no stackoverflow de Bill Karwin é exatamente o que você está procurando:

You have killed the process, but a dead process doesn't disappear from the process table until its parent process performs a task called "reaping" (essentially calling wait(3) for that process to read its exit status). Dead processes that haven't been reaped are called "zombie processes."

The parent process id you see for 31756 is process id 1, which always belongs to init. That process should reap its zombie processes periodically, but if it can't, they will remain zombies in the process table until you reboot.

Exceto neste caso, o processo pai é zsh. kill -9 o processo zsh e o defunct yes desaparecerá.

Confira htop para entender melhor as hierarquias de propriedade de processos (alternar a visualização plana / hierárquica com t ).

    
por 06.01.2016 / 16:20
4

Após killall -9 yes e mesmo após killall yes , o processo yes está inativo. Quando ps mostra um processo no estado Z e com <defunct> afte o nome do comando, isso não é um processo, é um zumbi. Zumbis estão mortos e você não pode matá-los mais.

O que está acontecendo aqui é que o processo yes está morto. Não está produzindo mais nada. No entanto, o processo de shell que está executando a substituição de comando leu muitos dados e está muito ocupado alocando memória para ele (e talvez não lidando de forma muito eficiente com a enorme quantidade de dados).

Execute ps -C yes l (sintaxe do Linux) para ver o processo pai de yes . É esse que você precisa matar. Outra maneira de identificá-lo é que ele é o responsável por 98,9% do tempo de CPU nesse top de saída.

    
por 07.01.2016 / 02:00