PDA

View Full Version : [C] select() e ricezione di SIGTERM


Manugal
14-04-2010, 21:38
Ciao a tutti!

Ho un ciclo strutturato in questo modo:


...
while(!shutDown){
FD_SET(POP3Socket,&rfds);
FD_SET(SMTPSocket,&rfds);
timeout.tv_sec = 3;
timeout.tv_usec = 0;
selRet=select(nfds,&rfds,NULL,NULL,&timeout);
if (selRet < 0 && errno != EINTR){
PrintError("select() error: ");
}
else if(selRet < 0)
continue;
else if(selRet==0){
FD_SET(POP3Socket,&rfds);
FD_SET(SMTPSocket,&rfds);
timeout.tv_sec = 3;
timeout.tv_usec = 0;
}
else if(FD_ISSET(POP3Socket,&rfds)){
POP3Conn(&pArgs[idx[0]]);
}
else if(FD_ISSET(SMTPSocket,&rfds)){
SMTPConn(&pArgs[idx[1]]);
}
}
LinuxMPShutDown(pArgs);
...


Il problema sorge quando gli invio il segnale SIGTERM (lo uso per chiudere l'applicazione). Se è ancora in corso la select(), come da documentazione, si interrompe, chiama il signal handler e poi riprende. Il fatto è che lui esegue la LinuxMPShutDown (che chiude i socket) che si trova fuori dal ciclo, ma poi comunque riprende la select() e ovviamente va in errore perché i socket sono stati chiusi. Come posso ovviare a questo problema? Non c'è proprio il modo di evitare che select() riparta?

Teo@Unix
14-04-2010, 22:17
... mmm ... come prima soluzione mi verrebbe in mente di istruire l'handler che viene chiamato quando arriva SIGTERM che setti il timeout a 0. In questo modo select() riprende ma va subito in timeout.
Allora quando controlli il valore di SelRetl che sarà 0 potesti aggiungere un'altro controllo su un'altra variabile, o meglio su un flag, che verrà settato ad uno dal signal handler. Se è 1 allora fai un bel break o quel che vuoi fare insomma..
Se è 0 è perchè c'è stato un timeout effettivo e prosegue come da copione.

(Non credo sia un problema cambire timeout in quel momento.... dovresti provare...)

Può andar bene?
Magari pensandoci su si può perfezionare però dovrebbe andare così e fare quel che hai chiesto...

cionci
15-04-2010, 09:06
Nel handler del segnale setta anche un flag che ti permette di rilevare che il programma deve essere terminato. Quindi se la select fallisce con quel flag settato allora non stampi alcun errore e termini l'esecuzione.

Manugal
15-04-2010, 10:56
Io nel signal handler setto il flag di shutDown e infatti mi accorgo che esce da quel ciclo e lancia la LinuxMPShutDown (ho un log file dove scrivo tutte le operazioni che faccio). Il problema strano è che dopo aver eseguito questa funzione, invece di uscire dal programma riesegue la select() e questa non ritorna -1 ma rileva che è stato settato il socket POP3 (cioè arriva a questo punto FD_ISSET(POP3Socket,&rfds)); in quel caso chiama la POP3Conn (che si occupa di accettare la connessione tramite accept(), ma la accept ritorna errore perché il socket era stato chiuso dalla precedente chiamata a LinuxMPShutDown). Quindi in realtà non è la select() che fallisce. Spero di essere stato più chiaro.

cionci
15-04-2010, 11:16
Puoi comunque controllare il flag shutDown prima della accept. Poi se la accept ti ritorna un errore (perché può comunque capitare) se è settato il flag non lo consideri un errore, ma lo gestisci come la normale chiusura di una sessione.

Manugal
15-04-2010, 11:29
Niente da fare. Sembra come se tornasse alla situazione precedente all'invio di SIGTERM (e quindi shutDown lo vede non settato persino prima della accept()). Questo è il log:


Thu Apr 15 12:26:01 2010 [Process 2001|Thread 2001] - [MULTIPROCESS] Creating server socket...

Thu Apr 15 12:26:01 2010 [Process 2001|Thread 2001] - [MULTIPROCESS] Server socket created.

Thu Apr 15 12:26:01 2010 [Process 2001|Thread 2001] - Listening on new POP3 connection...

Thu Apr 15 12:26:01 2010 [Process 2001|Thread 2001] - Listening on new SMTP connection...

Thu Apr 15 12:26:12 2010 [Process 2001|Thread 2001] - Accepting connection from 127.0.0.1:25

Thu Apr 15 12:26:12 2010 [Process 2001|Thread 2001] - Listening on new SMTP connection...

Thu Apr 15 12:26:23 2010 [Process 2001|Thread 2001] - Exiting from myMailServerd...

Thu Apr 15 12:26:23 2010 [Process 2001|Thread 2001] - Deallocating resources...

Thu Apr 15 12:26:25 2010 [Process 2001|Thread 2001] - All server resources deallocated.

Thu Apr 15 12:26:29 2010 [Process 2008|Thread 2008] - Listening on new SMTP connection...

Process 2008|Thread 2008 - POP3 accept() error:Transport endpoint is not connected


Exiting from myMailServerd viene stampato nel momento in cui invio SIGTERM. Deallocating resources e All server resources deallocated vengono stampati dalla LinuxMPShutDown() (che viene chiamata appunto per fare lo shutdown dell'applicazione). Il problema strano è che rientra dentro al ciclo dopo aver chiamato questa funzione.

Manugal
15-04-2010, 12:31
Ho trovato il problema!! :sofico:

In pratica quando chiamavo la SMTPConn (o la POP3Conn a seconda del tipo di connessione che arrivava), dentro tale funzione facevo la accept() e poi facevo la fork() per gestire la nuova connessione con un nuovo processo. Il problema nasceva dal fatto che nel processo figlio lanciavo una funzione e al ritorno da quella funzione invece di uscire dal processo facevo return. Ovviamente così facendo il padre terminava ma il figlio ritornava in quel famoso ciclo rifacendo la select() (di qui l'errore).

Grazie a tutti lo stesso. :)