While i was surfing the net i’ve found this article By Matteo Ferrone about Linux signals, that i want to repost:
A signal is an event sent by the kernel to a running program.
The signals can arrive at any time and software can choose what to do when it arrives: it can decide to ignore it or may decide to execute a signal handler and continue with what he did.
There are 31 different signals, and you can see them with:
kill -l
Of these there are 6 to be known by system administrators:
- SIGHUP used to tell a daemon to reload because its configuration files have been changed
- SIGINT sent to a process in the foreground when you hit Ctrl + C on your keyboard. Many programs, however ignore this action, such as the less command
- send SIGQUIT via Ctrl + , this ends the process but also causes the shell to write a core file to help the so-called post-mortem debug
- SIGTERM is the default signal to the kill command. You can consider this request as a soft closing and exit. It’s sent by init to all running processes on the shutdown
- SIGKILL is also used by init but only when SIGTERM does not work. This signal can not be caught or ignored by any process and its action is to terminate immediately the process. It’sused as a last resort only when the previous two fail, as SIGKILL don’t permit to the processes to do any action while closing.
- SISGEV (violation segmentation) is created inside the program itself, not externally as the others. It is created when the program tries to access a memory address that is no longer allocated to it. The default action is to terminate the program
These are the most important, but does not mean you don’t have to know the others!
Let’s see briefly how you can send signals.
In general, as we have said, a signal is sent to the kernel, but may originate in different places.
As mentioned above in the console, you can use the kill command:
$ kill -SIGTERM 15365 12984
The numbers are the identification of processes that will receive that signal.
Obviously you can only send signals to processes owned by the user running the kill command (or root).
If you use this command as root, be very careful about what process you are sending the signal!
Alternatively you can use pkill to kill.
The difference is that with the first we need the ID number, while for the latter, one can use other ways:
$ pkill -SIGHUP syslog-ng
$ pkill -SIGTERM -U matte
$ pkill -SIGKILL -P 16754
The first sends SIGHUP to all processes that are running syslog-ng, the second sends SIGTERM to all processes of the user matte and the third kills all processes that have as their parent process the one identified by the number 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