Mentre navigavo in rete ho trovato questo articolo di Matteo Ferrone che vi ripropongo:
Un segnale è un evento spedito dal kernel a un programma in esecuzione.
I segnali posso arrivare in qualsiasi momento e un software può scegliere cosa fare quando arriva: può decidere di ignorarlo o può decidere di eseguire un signal handler e continuare con quello che faceva.
Esistono 31 segnali differenti ed è possibili vederli con:
kill -l
Di questi ce ne sono 6 che devono essere conosciuti dagli amministratori di sistema:
- SIGHUP usato per dire a un demone di ricaricarsi perchè i suoi file di configurazione sono stati cambiati
- SIGINT mandato a un processo in foreground quando viene battuto Ctrl+C sulla tastiera. Molti programmi però ignorano questa azione, come ad esempio il comando less
- SIGQUIT spedito tramite Ctrl+; anche questo termina il processo ma fa in modo che la shell scriva un file core per aiutare il cosidetto post-mortem debug
- SIGTERM è il segnale di default del comando kill. Potete considerarla come una richiesta soft di chiusura e uscita. E’ inviato da init a tutti i processi in esecuzione durante lo spegnimento
- SIGKILL è usato anch’esso da init ma solo quanto SIGTERM non funziona. Questo segnale non può essere catturato o ignorato da nessun processo e la sua azione consiste nel terminare il processo. E’ usato come ultima risorsa solo quando i due precedenti falliscono, in quanto SIGKILL, al contrario di SIGTERM, non da ai processi la possibilità di sistemarsi
- SISGEV (segmentation voilation) è creato internamente al programma stesso, e non esternamente come gli altri. Viene creato quando il programma tenta di accedere a un indirizzo di memoria non più allocato ad esso. L’azione di default è quella di chiudere il programma
Questi sono i più importanti, ma non significa che non bisogna conoscere gli altri!
Vediamo brevemente come è possibile inviare segnali.
In generale abbiamo detto che sono inviati dal kernel, ma possono origine in luoghi diversi.
Come detto sopra da console si può usare il comando kill:
$ kill -SIGTERM 15365 12984
I numeri sono gli identificativi dei processi a cui spedire i segnali.
Ovviamente è possibile spedire segnali solo ai processi di proprietà dell’utente che esegue kill.
In caso contrario lanciato da root stando però molto attenti a quale processo state inviando il segnale!
In alternativa a kill si può usare pkill.
La differenza sta che per il primo bisogna sapere il numero identificativo, mentre per il secondo si possono usare altri modi:
$ pkill -SIGHUP syslog-ng
$ pkill -SIGTERM -U matte
$ pkill -SIGKILL -P 16754
Il primo invia SIGHUP a tutti i processi che stanno eseguendo syslog-ng; il secondo invia SIGTERM a tutti i processi dell’utente matte; il terzo “uccide” tutti i processi che hanno come processo padre quello identificato dal numero 16754.
Popular Posts:
- None Found
It’s worth noting that SIGHUP is also sent to processes when their controlling terminal or controlling process dies. Its original meaning was “hang up”, that your modem had hung up or your ASR 33 teletype had disconnected. 😎
Most processes respond to SIGHUP by saving their state (if any) as best they can and exiting. So, its an even “softer” exit request than SIGTERM. As such, its the first signal I try when I want a process to save and exit.
Be aware that SIGHUP is set to Ignored by programs run under the nohup(1) program and by a number of shells that automatically “nohup” processes put into the background.
There’s nothing that keeps a nohup-ed process from setting SIGHUP back to default or catching it. However, it is generally considered good *nix programming practice to check that a signal isn’t already ignored before setting a catcher function … unless you really, really need to catch it.
And with killall one can send signals directly to a running program name (man killall).
bye
11) SIGSEGV not SISGEV