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]

:confused:
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
:confused:
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 :D

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);

[cn73]

Temo di non seguirti più :(


Io ho un processo leader che genera di continuo (su richiesta di altri processi richiedenti che mettono la richiesta su una coda di messaggi) dei figli servi che si occupano di mettere sulla stessa coda di messaggi un dato che poi il processo richiedente preleverà...

Io ho messo in ascolto il servo leader della terminazione dei figli... immagino che "ogni tanto" il segnale venga ricevuto durante una fase delicata di accesso a questa coda di messaggi e questo mi sballi tutto...

[ilsensine]

Ripeto: sostituisci le tue chiamate a funzioni foo(a, b, c...) dove "foo" è una qualsiasi funzione che può terminare con EINTR, con IGNINT(foo(a, b, c...), ret) dove IGNINT è la macro che ti ho definito sopra. Così vai sul sicuro.

Nota che sleep necessita di un trattamento particolare, in quanto in caso di interruzione restituisce un valore > 0 e non setta errno.

[cn73]

Innanzitutto davvero grazie per la pazienza ;)
La cosa funziona, ma è indispensabile che capisca perchè :D

Vediamo: siccome il problema era che il segnale arrivava in modo asincrono e poteva fare fallire la msgrcv del leader, se questa msgrc risultava fallita (errno=EINR), la ripeto!

[ilsensine]

Esattamente. "fallire" non è il termine appropriato...diciamo che il kernel ti chiede se vuoi interrompere l'operazione, oppure andare avanti.
Nota che _qualsiasi_ operazione pendente che richiede una syscall viene interrotta (anche una semplice printf! )

[cn73]

Perfetto...ora è tutto chiaro ;)

Una domanda: compilando il mio programma sotto Unix IBM AIX ho notato un errore quando utilizzavo la costante WAIT_MYPGRP definita in wait.h. Evidentemente le versioni delle librerie sono vecchie. Allora ho aggiunto:


#ifndef WAIT_MYPGRP
#define WAIT_MYPGRP 0 /* tutti i processi di un gruppo */
#endif


è corretto?

[ilsensine]

Se la waitpid dell'AIX è conforme agli stessi standard di quella su linux (SVr4 e POSIX.1), sì. Altrimenti non è detto che il comportamento sia quello che ti aspetti.

[cn73]

Certo! Se metto 0 si comporta allo stesso modo, era solo per chiarezza.