[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Processo immortale



On Tue, Oct 02, 2018 at 09:04:09PM +0200, Davide Prina wrote:
> On 02/10/2018 09:19, Paolo Nicorelli wrote:
> 
> > C'è il processo utente con PID 9583 che gira dal 21 Agosto.
> 
> > kill -9 e sudo kill -9 non danno errori ma il processo rimane li
> > Non è zombie, è in stato R
> > pstree dice che il padre è init.
> 
> il comando kill -9 lancia una chiamata asincrona per l'uccisione del
> processo indicato, se però il processo sta eseguendo una system call,
> allora questa può bloccare SIGKILL fino al suo completamento.
> 
> Una system call può non terminare o impiegare tempi anche biblici per
> diversi motivi, ad esempio:
> * si sta cercando di accedere ad una risorsa (solitamente remota) che
> non è disponibile (es: un file system NFS) [in questo caso dovrebbe
> bastare rendere disponibile la risorsa, es: montare il file system
> NFS]
> * un bug hardware
> * un bug di Linux
> 
> Però penso che gli ultimi due casi dovrebbero porre il processo nello
> stato D.

Forse Z o X dopo tutti i kill che ha dato, fosse stato D sarebbe stato
nella condizione che descrivi sopra, R dovrebbe essere regolarmente "killabile":


               D    uninterruptible sleep (usually IO)
               R    running or runnable (on run queue)
               S    interruptible sleep (waiting for an event to complete)
               T    stopped by job control signal
               t    stopped by debugger during the tracing
               W    paging (not valid since the 2.6.xx kernel)
               X    dead (should never be seen)
               Z    defunct ("zombie") process, terminated but not reaped by its parent


Sarebbe interessante vedere il contenuto dello script


> Visto che il tuo processo è nello stato di running R dovresti capire
> cosa sta aspettando per risvegliarlo dallo sleep.
> 
> Per individuare cosa sta aspettando si può provare in diversi modi:
> * cat /proc/PID/syscall
> * lsof -p PID (come ti hanno già suggerito)
> * strace -p PID
> * gdb PERCORSO_ALL'ESEGUBILE PID
> 
> Guardando quanto hai postato per lsof
> > php 9583 userXXX 3u sock 0,8 0t0 485569960 can't identify protocol
> > php 9583 userXXX 5u sock 0,8 0t0 485583014 can't identify protocol
> 
> direi che il problema potrebbe essere causato da questi due.
> Potrebbero essere dei socket che non sono stati chiusi correttamente
> 
> dovresti vederli in stato CLOSE_WAIT anche eseguendo questo:
> # netstat -putan
> 
> Però:
> 1) non so se è possibile terminare dei socket in quello stato... se
> non uccidendo il processo che li ha generati :-(
> 
> 2) se il problema è questo, secondo me, l'unica è correggere il
> sorgente dove vengono aperti e farglieli chiudere correttamente... e a
> questo punto non so se puoi sostituire l'eseguibile (può essere uno
> script)
> 
> Provare ad ucciderlo con gdb:
> gdb -p PID
> > kill
> Kill the program being debugged? (y or n) y
> > quit
> 
> Se non funziona neanche così, dopo aver fatto il punto 2 devi
> riavviare la macchina... o far si che il processo abbia un altro nome
> (in modo che possa partire) e lasciare quello attivo in sleep.
> 
> Ciao
> Davide
> 
> -- 
> Dizionari: http://linguistico.sourceforge.net/wiki
> Petizione contro il formato ms-ooxml:
> http://www.noooxml.org/petition
> Non autorizzo la memorizzazione del mio indirizzo su outlook

-- 
Felipe Salvador


Reply to: