Pubblicherò questo come una risposta in modo che ci sia una sorta di risoluzione se questo si rivela essere il problema.
Uno stato di uscita pari a 0 indica un'uscita normale da un programma riuscito. Un programma in uscita può scegliere qualsiasi numero intero compreso tra 0 e 255 come stato di uscita. Convenzionalmente, i programmi usano piccoli valori. I valori 126 e superiori sono usati dalla shell per segnalare condizioni speciali, quindi è meglio evitarli.
A livello di API C, i programmi riportano uno stato a 16 bit¹ che codifica sia lo stato di uscita del programma sia il segnale che lo ha ucciso, se presente.
Nella shell, lo stato di uscita di un comando (salvato in $?
) unisce lo stato di uscita effettivo del programma e il valore del segnale: se un programma viene ucciso da un segnale, $?
viene impostato su un valore maggiore di 128 (con la maggior parte delle shell, questo valore è 128 più il numero del segnale; ATT ksh usa 256 + numero del segnale e yash usa 384 + numero del segnale, il che evita l'ambiguità, ma gli altri gusci non hanno seguito l'esempio).
In particolare, se $?
è 0, il tuo programma è uscito normalmente.
Si noti che questo include il caso di un processo che riceve SIGTERM, ma ha un gestore di segnali per esso e alla fine esce normalmente (forse come conseguenza indiretta del segnale SIGTERM, forse no).
Per rispondere alla domanda nel titolo, SIGTERM non viene mai inviato automaticamente dal sistema. Ci sono alcuni segnali che vengono inviati automaticamente come SIGHUP quando un terminale si spegne, SIGSEGV / SIGBUS / SIGILL quando un processo fa cose che non dovrebbe fare, SIGPIPE quando scrive su un tubo / socket rotto, ecc. E ci sono alcuni segnali inviati a causa della pressione di un tasto in un terminale, principalmente SIGINT per Ctrl+ C, SIGQUIT per Ctrl+ \e SIGTSTP per Ctrl+ Z, ma SIGTERM non è uno di quelli. Se un processo riceve SIGTERM, qualche altro processo ha inviato quel segnale.
¹ parlando approssimativamente