Processi <defunct>

[cn73]

Mi pare di avere capito che un processo è segnalato come defunct se è terminato, ma una qualche risorsa ad esso associata è ancora allocata. E se tali risorse sono ad esempio risorse IPC (condivise con altri processi ancora attivi) che non posso deallocare...?? devo aspettare che terminino tutti iprocessi per eliminare la lista infinita di defunct?

[ilsensine]

http://www.webmasterworld.com/forum40/1032.htm

[cn73]

Grazie.
Mi registro...

[ilsensine]

L'ho semplicemente trovato con google...credo risponda alla tua domanda

[cn73]

Mi pare di avere capito che il sistema necessita di mantenere questi id in quanto il padre potrebbe volere essere informato della loro terminazione... Ma se a me non interessa... ?
Nel mio specifico caso non posso inserire una wait del processo...

[cn73]

Originariamente inviato da ilsensine

L'ho semplicemente trovato con google...credo risponda alla tua domanda

Bisogna registrarsi per accedere a quel forum...probabilmente tu eri già registrato...

[ilsensine]

?
No, mai visto in vita mia

Cmq tieni conto che quando un figlio muore, il padre dovrebbe ricevere notifica tramite un SIGCHLD.

[cn73]

Allora basterebbe mettersi in ascolto con una signal(SIGCHLD,SIG_DFL ) ?

[cn73]

No appena provato i defunct non scompaiono...

[ilsensine]

No; intendevo che dentro l'handler si SIGCHLD puoi eseguire la wait/waitpid...
L'azione di default di SIGCHLD è ignorare il segnale; ci fai ben poco...

[cn73]

Capisco...senti...ma così facendo, obbligo il padre ad aspettare il figlio vero? (con la wait nell'handler della signal)

[ilsensine]

Se sei nell'handler, vuol dire che il figlio è _già_ terminato, e attende solo la wait...

[cn73]

giusto!

[cn73]

Ho risolto mettendo signal(SIGCHLD,SIG_IGN);

comportamento strano: di default dovrebbe ignorare,
però se metto SIG_DFL i defunct appaiono lo stesso... sai darmi una spiegazione??

[ilsensine]

No...è tra l'altro scorretto che ignorando il segnale gli zombie scompaiono.

[cn73]

Si penso sia un comportamento troppo legato alla versione di Linux, Unix...

Ho trovato delle informazioni, le riporto in caso possano essere utili a qualcuno:

Altrettanto rilevante è il caso in cui il figlio termina prima del padre, perché non è detto che il padre possa ricevere immediatamente lo stato di terminazione, quindi il kernel deve comunque conservare una certa quantità di informazioni riguardo ai processi che sta terminando.

Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e memorizzando alcuni dati essenziali, come il pid, i tempi di CPU usati dal processo e lo stato di terminazione, mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal padre sono chiamati zombie, essi restano presenti nella tabella dei processi ed in genere possono essere identificati dall'output di ps per la presenza di una Z nella colonna che ne indica lo stato (vedi tab. 3.5). Quando il padre effettuerà la lettura dello stato di uscita anche questa informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi completamente conclusa.


...

La possibilità di avere degli zombie deve essere tenuta sempre presente quando si scrive un programma che deve essere mantenuto in esecuzione a lungo e creare molti figli. In questo caso si deve sempre avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in genere questo si fa attraverso un apposito signal handler, che chiama la funzione wait. Questa operazione è necessaria perché anche se gli zombie non consumano risorse di memoria o processore, occupano comunque una voce nella tabella dei processi, che a lungo andare potrebbe esaurirsi.


....

In generale dunque, quando non interessa elaborare lo stato di uscita di un processo, si può completare la gestione della terminazione installando un gestore per SIGCHLD il cui unico compito sia quello chiamare waitpid per completare la procedura di terminazione in modo da evitare la formazione di zombie.

...

Segue un esempio di gestore:

: void HandSigCHLD(int sig) 
02: { 
03:     int errno_save; 
04:     int status; 
05:     pid_t pid; 
06:     /* save errno current value */ 
07:     errno_save = errno; 
08:     /* loop until no */ 
09:     do { 
10:         errno = 0; 
11:         pid = waitpid(WAIT_ANY, &status, WNOHANG); 
12:         if (pid > 0) { 
13:             debug("child %d terminated with status %x\n", pid, status); 
14:         } 
15:     } while ((pid > 0) && (errno == EINTR)); 
16:     /* restore errno value */ 
17:     errno = errno_save; 
18:     /* return */ 
19:     return; 
20: }

[cn73]

grrrrrrrrr...i defunct spariscono si...ma la chiamata all'handler sembra interferire con la gestione delle code di messaggi...sballandomi tutto

[ilsensine]

Dai una occhiata alla documentazione delle funzioni che usi, in particolare all'errore EINTR

[cn73]

EINTR Interrupted function call. Una funzione di libreria è stata interrotta. In genere questo avviene causa di un segnale asincrono al processo che impedisce la conclusione della chiamata. In questo caso è necessario ripetere la chiamata alla funzione.

Capisco...ma come posso ripetere quella chiamata?? Non c'è modo di ricevere il segnale NON mentre esegue una funzione di libreria?

[ilsensine]

Il segnale può arrivare in qualsiasi momento, ad esempio quando il processo è in attesa in kernel mode di un evento (tipo lo sblocco di un semaforo, giusto per rimanere in tema). In questa situazione, la syscall termina con un errore EINTR.

Soluzione banale:

#define IGNINT(fnc, retval) do { \
  retval = fnc; \
} while(retval<0 && errno==EINTR)
(...)
int retval;
IGNINT(semop(semid, &sop, 1), retval);