Use trap to capture signals like this:
i=-1;while((++i<33));
do
trap "echo $i >> log.txt" $i;
done
And close the terminal by force.
The content in log.txt is then (under redhat linux):
1
18
1
17
0
Where these signals from?
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
The first signal is SIGHUP; that gets sent to all processes in the process group when the terminal disconnects (hangs up – hence HUP).
The second signal is SIGCONT (thanks, SiegeX, for the numbers). This is slightly surprising; it suggests you had a job stopped in the background which had to be allowed to run again.
The third signal is another SIGHUP. This was likely sent to ensure that the continued process got its turn to exit, but was sent to the whole process group. (See the POSIX standard for information on process groups, etc.).
The fourth signals is a SIGCHLD, indicating that a child process died and the corpse is available (well, the status is available).
The final signal, 0, is the shells internal pseudo-signal indicating that it is exiting.
You can do:
to echo ‘Bye’ when the shell exits under control for any reason. You chose to echo the signal number to the file instead. Since the shell exits at this point, that is the last signal message that is seen. Its parent process should get a SIGCHLD signal because the shell died.
FWIW, on MacOS X 10.6.7, I ran your test. There isn’t a signal 32 on MacOS X, and some of the mappings are different, and the sequence of signals sent is also different:
The signals captured in one run were:
In a second run, I got:
The SIGINT first is surprising — I don’t think I can explain that unless it simply means an incomplete write of some sort (it should have read 20 but the SIGHUP caused a problem). I’m not sure that I can explain the SIGCHLD signals either; the SIGHUP and ‘exit’ trap are as before.
To some extent, though, the signals are system specific – or so it seems. The SIGHUP is common and constant, though.