Non posso uccidere un processo di sonno


13

Non riesco a uccidere -9 un processo che si trova in uno stato di sonno interrompibile (S):

[root@jupiter ~]# ps -elf | grep yum
4 S root     16790     1  0  75   0 - 73779 -      Jan15 ?        00:00:04 /usr/bin/python /usr/bin/yum -y install python-pip
[root@jupiter ~]# kill -9 16790
[root@jupiter ~]# ps -elf | grep yum
4 S root     16790     1  0  75   0 - 73779 -      Jan15 ?        00:00:04 /usr/bin/python /usr/bin/yum -y install python-pip

Com'è possibile? C'è un modo per terminare il processo senza riavviare?

BOUNTY: Sono davvero più interessato a una spiegazione di come sia possibile che ciò accada.

AGGIORNARE: questo è l'output di lsof:

[root @ jupiter ~] # lsof -p 16790
COMANDO PID UTENTE TIPO FD MISURA DISPOSITIVO / OFF NOME NOME
yum 16790 root cwd DIR 1166.56842 4096 16886249 / home / del
yum 16790 radice rtd DIR 253,0 4096 2 /
yum 16790 radice txt REG 253,0 8304 336177337 / usr / bin / python
yum 16790 mem radice REG 253,0 144776 346128569 /lib64/ld-2.5.so
yum 16790 mem radice REG 253,0 1718232 346128573 /lib64/libc-2.5.so
yum 16790 mem radice REG 253,0 23360 346128599 /lib64/libdl-2.5.so
yum 16790 mem radice REG 253,0 145872 346128584 /lib64/libpthread-2.5.so
yum 16790 mem radice REG 253,0 615136 346128602 /lib64/libm-2.5.so
yum 16790 mem radice REG 253,0 1244792 336171087 /usr/lib64/libpython2.4.so.1.0
yum 16790 mem radice REG 253,0 95464 346128744 /lib64/libselinux.so.1
yum 16790 mem radice REG 253,0 53448 346128750 /lib64/librt-2.5.so
yum 16790 mem radice REG 253,0 13960 336187564 /usr/lib64/libplds4.so
yum 16790 mem radice REG 253,0 58400 346128752 /lib64/libgcc_s-4.1.2-20080825.so.1
yum 16790 mem radice REG 253,0 78384 336173796 /usr/lib64/libelf-0.137.so
yum 16790 mem radice REG 253,0 1139672 336187570 /usr/lib64/librpmdb-4.4.so
yum 16790 mem radice REG 253,0 407792 336187568 /usr/lib64/librpmio-4.4.so
yum 16790 mem radice REG 253,0 233144 336171420 /usr/lib64/libnspr4.so
yum 16790 mem radice REG 253,0 375656 336187569 /usr/lib64/libsqlite3.so.0.8.6
yum 16790 mem radice REG 253,0 17992 336187563 /usr/lib64/libplc4.so
yum 16790 mem radice REG 253,0 386784 336187571 /usr/lib64/librpm-4.4.so
yum 16790 mem radice REG 253,0 154776 336170228 /usr/lib64/librpmbuild-4.4.so
yum 16790 mem radice REG 253,0 647608 346128759 /lib64/libglib-2.0.so.0.1200.3
yum 16790 mem radice REG 253,0 1297136 336176959 /usr/lib64/libxml2.so.2.6.26
yum 16790 mem radice REG 253,0 15584 346128756 /lib64/libtermcap.so.2.0.8
yum 16790 mem radice REG 253,0 1234328 336187566 /usr/lib64/libnss3.so
yum 16790 mem radice REG 253,0 18152 346128670 /lib64/libutil-2.5.so
yum 16790 mem radice REG 253,0 34240 336177071 /usr/lib64/libpopt.so.0.0.0
yum 16790 mem radice REG 253,0 67792 336187567 /usr/lib64/libbz2.so.1.0.3
yum 16790 mem radice REG 253,0 143144 346128763 /lib64/libexpat.so.0.5.0
yum 16790 mem radice REG 253,0 56434416 336184082 / usr / lib / locale / locale-archive
yum 16790 mem mem REG 253,0 132656 336560181 /usr/lib64/python2.4/site-packages/rpm/_rpmmodule.so
yum 16790 mem radice REG 253,0 154016 336187565 /usr/lib64/libnssutil3.so
yum 16790 mem radice REG 253,0 96885 345638632 /usr/local/greenplum-loaders-3.3.0.0-build-3/lib/libz.so.1.2.3
yum 16790 mem radice REG 253,0 247496 346128741 /lib64/libsepol.so.1
yum 16790 mem radice REG 253,0 369144 336168883 /usr/lib64/libsoftokn3.so
yum 16790 mem radice REG 253,0 312336 336178453 /usr/lib64/libfreebl3.so
yum 16790 mem radice REG 253,0 20240 336530067 /usr/lib64/python2.4/lib-dynload/timemodule.so
yum 16790 mem radice REG 253,0 25048 336529953 /usr/lib64/python2.4/lib-dynload/stropmodule.so
yum 16790 mem radice REG 253,0 18984 336530051 /usr/lib64/python2.4/lib-dynload/cStringIO.so
yum 16790 mem radice REG 253,0 21816 336529943 /usr/lib64/python2.4/lib-dynload/collectionsmodule.so
yum 16790 mem radice REG 253,0 52152 336530044 /usr/lib64/python2.4/lib-dynload/_socketmodule.so
yum 16790 mem radice REG 253,0 17200 336530045 /usr/lib64/python2.4/lib-dynload/_ssl.so
yum 16790 mem radice REG 253,0 315080 346128749 /lib64/libssl.so.0.9.8e
yum 16790 mem radice REG 253,0 1366912 346128748 /lib64/libcrypto.so.0.9.8e
yum 16790 mem radice REG 253,0 190976 336187552 /usr/lib64/libgssapi_krb5.so.2.2
yum 16790 mem radice REG 253,0 613928 336184245 /usr/lib64/libkrb5.so.3.3
yum 16790 mem radice REG 253,0 11760 346128747 /lib64/libcom_err.so.2.1
yum 16790 mem radice REG 253,0 153720 336181723 /usr/lib64/libk5crypto.so.3.1
yum 16790 mem radice REG 253,0 35984 336177832 /usr/lib64/libkrb5support.so.0.1
yum 16790 mem radice REG 253,0 9472 346128681 /lib64/libkeyutils-1.2.so
yum 16790 mem radice REG 253,0 92816 346128730 /lib64/libresolv-2.5.so
yum 16790 mem radice REG 253,0 75384 336530050 /usr/lib64/python2.4/lib-dynload/cPickle.so
yum 16790 mem radice REG 253,0 23736 336530064 /usr/lib64/python2.4/lib-dynload/structmodule.so
yum 16790 mem radice REG 253,0 27336 336528958 /usr/lib64/python2.4/lib-dynload/operator.so
yum 16790 mem radice REG 253,0 21520 336529958 /usr/lib64/python2.4/lib-dynload/zlibmodule.so
yum 16790 mem radice REG 253,0 37944 336528952 /usr/lib64/python2.4/lib-dynload/itertoolsmodule.so
yum 16790 mem radice REG 253,0 21528 336528929 /usr/lib64/python2.4/lib-dynload/_localemodule.so
yum 16790 mem radice REG 253,0 21208 336529939 /usr/lib64/python2.4/lib-dynload/binascii.so
yum 16790 mem radice REG 253,0 12080 336530062 /usr/lib64/python2.4/lib-dynload/shamodule.so
yum 16790 mem radice REG 253,0 13168 336530058 /usr/lib64/python2.4/lib-dynload/md5module.so
yum 16790 mem radice REG 253,0 18000 336529947 /usr/lib64/python2.4/lib-dynload/mathmodule.so
yum 16790 mem radice REG 253,0 12504 336529934 /usr/lib64/python2.4/lib-dynload/_randommodule.so
yum 16790 mem radice REG 253,0 15320 336528948 /usr/lib64/python2.4/lib-dynload/fcntlmodule.so
yum 16790 mem radice REG 253,0 32816 336530049 /usr/lib64/python2.4/lib-dynload/bz2.so
yum 16790 mem radice REG 253,0 8608 336529946 /usr/lib64/python2.4/lib-dynload/grpmodule.so
yum 16790 mem radice REG 253,0 38696 336529819 /usr/lib64/python2.4/site-packages/cElementTree.so
yum 16790 mem radice REG 253,0 42672 336530047 /usr/lib64/python2.4/lib-dynload/arraymodule.so
yum 16790 mem radice REG 253,0 9368 336528915 /usr/lib64/python2.4/lib-dynload/_bisect.so
yum 16790 mem radice REG 253,0 74992 336529944 /usr/lib64/python2.4/lib-dynload/datetime.so
yum 16790 mem radice REG 253,0 372912 336560510 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
yum 16790 mem radice REG 253,0 7120 336529937 /usr/lib64/python2.4/lib-dynload/_weakref.so
yum 16790 mem radice REG 253,0 17496 336528966 /usr/lib64/python2.4/lib-dynload/selectmodule.so
yum 16790 mem radice REG 253,0 46448 336528961 /usr/lib64/python2.4/lib-dynload/pyexpat.so
yum 16790 mem radice REG 253,0 33896 336529820 /usr/lib64/python2.4/site-packages/_sqlite.so
yum 16790 mem radice REG 253,0 41784 336530075 /usr/lib64/python2.4/site-packages/_sqlitecache.so
yum 16790 mem radice REG 253,0 25104 336530066 /usr/lib64/python2.4/lib-dynload/termios.so
yum 16790 mem radice REG 253,0 7280 336530065 /usr/lib64/python2.4/lib-dynload/syslog.so
yum 16790 mem radice REG 253,0 25464 336265457 /usr/lib64/gconv/gconv-modules.cache
yum 16790 mem radice REG 253,0 66544 336528926 /usr/lib64/python2.4/lib-dynload/_cursesmodule.so
yum 16790 mem radice REG 253,0 380336 336181932 /usr/lib64/libncurses.so.5.5
yum 16790 mem radice REG 253,0 405880 336529957 /usr/lib64/python2.4/lib-dynload/unicodedata.so
yum 16790 mem radice REG 253,0 24576 236520047 /var/lib/rpm/__db.001
yum 16790 mem radice REG 253,0 53880 346128424 /lib64/libnss_files-2.5.so
yum 16790 mem radice REG 253,0 23736 346128408 /lib64/libnss_dns-2.5.so
yum 16790 mem radice REG 253,0 1318912 236520050 /var/lib/rpm/__db.002
yum 16790 mem radice REG 253,0 663552 236520051 /var/lib/rpm/__db.003
yum 16790 mem radice REG 253,0 769074 336174965 /usr/share/locale/en_US/LC_MESSAGES/redhat-dist.mo
yum 16790 root 0u CHR 136,8 0t0 10 / dev / pts / 8 (cancellato)
yum 16790 root 1u CHR 136,8 0t0 10 / dev / pts / 8 (cancellato)
yum 16790 root 2u CHR 136,8 0t0 10 / dev / pts / 8 (cancellato)
yum 16790 root 3u unix 0xffff8104388d2e40 0t0 4675113 socket
yum 16790 radice 4w REG 253,0 0 236522326 /var/log/yum.log
yum 16790 root 5u REG 253,0 605184 236520025 /var/cache/yum/WANdisco-dev/primary.xml.gz.sqlite
yum 16790 root 6u REG 253,0 20480 236524002 /var/cache/yum/addons/primary.sqlite.old.tmp (cancellato)
yum 16790 root 7u REG 253,0 12578816 236519970 /var/cache/yum/base/primary.xml.gz.sqlite.old.tmp (cancellato)
yum 16790 root 8u REG 253,0 17972224 236523993 /var/cache/yum/epel/317109b44f1b0b40d910dc60c9080e62c7f4b16a-primary.sqlite.old.tmp (cancellato)
yum 16790 root 9u REG 253,0 967680 236524055 /var/cache/yum/extras/primary.sqlite.old.tmp (cancellato)
yum 16790 root 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (cancellato)
yum 16790 root 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (cancellato)
yum 16790 root 12r REG 253,0 65204224 236519434 / var / lib / rpm / Pacchetti
yum 16790 radice 13r REG 253,0 45056 236519438 / var / lib / rpm / Nome
yum 16790 root 14u IPv4 4675317 0t0 TCP jupiter.example.com:33597->riksun.riken.go.jp:http (STABILITO)
yum 16790 root 15u IPv4 4675939 0t0 TCP jupiter.example.com:52708->freedom.itsc.cuhk.edu.hk:http (CLOSE_WAIT)
yum 16790 root 16r REG 253,0 65204224 236519434 / var / lib / rpm / Pacchetti
yum 16790 radice 17r REG 253,0 45056 236519438 / var / lib / rpm / Nome
yum 16790 radice 18r REG 253,0 12288 236519440 / var / lib / rpm / Pubkeys
yum 16790 root 20r FIFO 0,6 0t0 4676024 pipe
yum 16790 radice 24w FIFO 0,6 0t0 4676024 tubo

Uccidi gli altri processi che manipolano lo stesso lucchetto e probabilmente si sbloccherà.
David Schwartz,

@ David - Non posso uccidere nessuno dei processi yum nell'elenco di processi sopra; hanno tutti lo stesso problema.
del

Ho rimosso le righe extra perché non aggiungevano ulteriori informazioni e rendevano più difficile leggere il tuo post.
terdon,

@slm - lsof mostra i socket TCP su riksun.riken.go.jp:80 (ESTABLISHED) e freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT). Immagino che potrebbe essere?
del

@slm - Vedi la mia domanda aggiornata.
del

Risposte:


18

Un processo in stato S o D è di solito in una chiamata di sistema bloccante, come leggere o scrivere su un file o sulla rete, in attesa del completamento di un programma chiamato o in attesa di semafori o altre primitive di sincronizzazione. Andrà nello stato di sonno durante l'attesa.

Non è possibile "svegliarlo": procederà solo quando saranno disponibili i dati / la risorsa che sta aspettando. Questo è tutto normale e previsto, e solo un problema quando si tenta di ucciderlo.

Puoi provare e usare strace -p pidper scoprire quale chiamata di sistema è attualmente in corso per il processo pid.

Da Wikipedia :

Uno stato di sonno ininterrotto è uno stato di sonno che non gestirà immediatamente un segnale. Si attiverà solo a seguito della disponibilità di una risorsa attesa o dopo che si verificherà un timeout durante l'attesa (se specificato quando messo in sospensione). Viene utilizzato principalmente dai driver di dispositivo in attesa di I / O su disco o rete (input / output). Quando il processo si interrompe ininterrottamente, i segnali accumulati durante il sonno verranno notati quando il processo ritorna dalla chiamata di sistema o dalla trap.

Un processo bloccato in una chiamata di sistema è in modalità di sospensione ininterrotta, che come dice il nome è ininterrotta anche da root.

Normalmente, i processi non possono bloccare SIGKILL. Ma il codice del kernel può ed i processi eseguono il codice del kernel quando chiamano le chiamate di sistema, durante le quali il codice del kernel blocca tutti i segnali. Pertanto, se una chiamata di sistema si blocca indefinitamente, potrebbe non esserci alcun modo per interrompere il processo. SIGKILL avrà effetto solo quando il processo completa la chiamata di sistema.


2
Pensavo che solo i processi ininterrotti del sonno fossero in grado di bloccare SIGKILL. Anche i processi di sonno interrompibili sono in grado di farlo? In tal caso, qual è la differenza tra loro?
del

1
Entrambi gli stati S e D sono in effetti ininterrotti, semplicemente perché troppo complessi da programmare nel kernel e perché in passato avrebbero dovuto essere solo di durata molto breve. Sebbene il kernel si sia evoluto per includere NFS e altri casi che potrebbero richiedere molto più tempo, purtroppo le attese di blocco del kernel non sono mai state abolite.
harrymc,

3
Interessante. Hai qualche riferimento per questo? Tutto ciò che posso trovare su Google sembra dire che i processi interrompibili non dovrebbero essere in grado di ignorare SIGKILL.
del

1
Sembra solo contraddire tutto ciò che ho letto sui dormi interrompibili, e sono un po 'scettico di essermi imbattuto in un comportamento non documentato. ad es. controllare i seguenti 2 collegamenti. Sto fraintendendo qualcosa? (1) "In un sonno interrompibile, il processo potrebbe essere svegliato per l'elaborazione dei segnali." (2) "Se viene generato un segnale per un processo in questo stato, l'operazione viene interrotta e il processo viene riattivato dalla consegna di un segnale."
del

1
Una chiamata di sistema è interrompibile o non dipende solo da come è stata programmata. Una volta che uno è all'interno del kernel, allora tutto va bene.
harrymc,

10

Sfondo su un processo di sonno

Potresti dare un'occhiata a questo post Unix e Linux.

Nello specifico questa risposta, /unix//a/5648/7453 .

Estratto da quel post

kill -9 (SIGKILL) funziona sempre, a condizione che tu abbia l'autorizzazione per terminare il processo. Fondamentalmente o il processo deve essere avviato da te e non essere setuid o setgid, oppure devi essere root. C'è un'eccezione: anche il root non può inviare un segnale fatale al PID 1 (il processo di init).

Comunque uccidere -9 non è garantito per funzionare immediatamente. Tutti i segnali, incluso SIGKILL, vengono inviati in modo asincrono: il kernel potrebbe impiegare del tempo per consegnarli. Di solito, per emettere un segnale sono necessari al massimo alcuni microsecondi, proprio il tempo impiegato dall'obiettivo per ottenere un intervallo di tempo. Tuttavia, se il bersaglio ha bloccato il segnale, il segnale verrà messo in coda fino a quando il bersaglio non lo sblocca.

Normalmente, i processi non possono bloccare SIGKILL. Ma il codice del kernel può e i processi eseguono il codice del kernel quando chiamano le chiamate di sistema. Il codice del kernel blocca tutti i segnali quando si interrompe la chiamata di sistema si tradurrebbe in una struttura di dati mal formata da qualche parte nel kernel, o più in generale nella violazione di un invariante del kernel. Quindi se (a causa di un bug o di un errore di progettazione) una chiamata di sistema si blocca indefinitamente, potrebbe effettivamente non esserci modo di terminare il processo. (Ma il processo verrà interrotto se mai completa la chiamata di sistema.)

...

...

Consiglio vivamente di leggere il resto di quella risposta!

Uccidere un processo bloccato da una risorsa (file o rete)

Ecco 2 cose da provare

1. Rimozione del file .pid di yum

È presente un file di blocco yum? Cosa succede quando rimuovi quel file di blocco? Penso che potrebbe consentirgli di procedere.

rm /var/run/yum.pid

2. Forzare eventuali CLOSE_WAITconnessioni TCP sospese chiuse

A CLOSE_WAITè descritto come segue:

CLOSE_WAIT Indica che il server ha ricevuto il primo segnale FIN dal client e che la connessione è in fase di chiusura

Quindi questo essenzialmente significa che il suo è uno stato in cui socket è in attesa che l'applicazione esegua close ()

Un socket può trovarsi nello stato CLOSE_WAIT indefinitamente finché l'applicazione non lo chiude. Gli scenari difettosi sarebbero come perdita di filedescriptor, il server non viene eseguito close () sul socket che porta ad accumulare socket close_wait

NOTA: estratto dal sito Web di Technet .

Ci sono 2 strumenti che puoi provare a utilizzare per raggiungere questo obiettivo.

Questi strumenti funzionano simulando lo scambio FIN-ACK-RST necessario per la chiusura completa di una connessione TCP.

Killcx funziona creando un pacchetto SYN falso con un SeqNum falso, falsificando l'IP / la porta del client remoto e inviandolo al server. Forzerà un processo figlio che acquisirà la risposta del server, estrarrà i 2 valori magici dal pacchetto ACK e li userà per inviare un pacchetto RST contraffatto. La connessione verrà quindi chiusa.

NOTA: estratto dal sito Web di Killcx .

Usando la taglierina

Taglia la connessione specifica tra le due coppie di numeri ip / porta fornite.

# cutter ip-address-1 port-1 ip-address-2 port-2
% cutter 200.1.2.3 22 10.10.0.45 32451

Utilizzando Killcx

Taglia le connessioni all'ip e alla porta remote.

# killcx remote-ip-address:port
% killcx 120.121.122.123:1234

risorse


La rimozione del file di blocco non ha avuto alcun effetto.
del

1
Questo è su una macchina di produzione e sfortunatamente questi due strumenti hanno dipendenze che non posso installare. Ho provato /etc/init.d/networking restart e non ha fatto nulla. In realtà, ora sono più interessato a capire perché questo può accadere (poiché non pensavo che i processi di sonno interrompibili fossero in grado di ignorare SIGKILL) piuttosto che come posso risolvere questo problema.
del

Il riavvio della rete avrebbe lo stesso effetto, quindi il blocco su I / O, se è in effetti ciò che il processo sta aspettando, sta altrove.
slm

1

Potresti provare ad uccidere il processo genitore. Usa ps per controllare:

ps xjf -C yum

Quindi kill -9qualsiasi processo genitore.


Il processo genitore è init (quinta colonna nel mio output).
del

1

Potrebbe valere la pena collegarsi al processo con strace per vedere se è veramente inattivo o bloccato su un'operazione di I / O. Potrebbe fornire ulteriori indizi sulla questione forse.

strace -pPID

Da quello che ho letto non c'è modo di uccidere questo processo se non riavviare. Se il processo non sta consumando alcun tempo notevole della CPU, è improbabile che crei alcun impatto negativo sul server.


Grazie per il suggerimento, ma il processo principale è init (vedi la quinta colonna nel mio output).
del

Per quanto riguarda la tua risposta rivista, strace si attacca al processo ma non genera nulla.
del

1

Potrebbe essere che sta aspettando un processo figlio? Adoro ps fauxperché ti dirà se ci sono processi figlio e se, che potresti aver bisogno di uccidere.


No, questo processo non ha alcun processo figlio.
del
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.