SIGCHLD not trapped

[Fedele Giuseppe]

I have the following ksh script

#!/bin/ksh

trap 'echo RECEIVED SIGNAL 1' 1
trap 'echo RECEIVED SIGNAL 2' 2
trap 'echo RECEIVED SIGNAL 3' 3
trap 'echo RECEIVED SIGNAL 4' 4
trap 'echo RECEIVED SIGNAL 5' 5
trap 'echo RECEIVED SIGNAL 6' 6
trap 'echo RECEIVED SIGNAL 7' 7
trap 'echo RECEIVED SIGNAL 8' 8
trap 'echo RECEIVED SIGNAL 9' 9
trap 'echo RECEIVED SIGNAL 10' 10
trap 'echo RECEIVED SIGNAL 11' 11
trap 'echo RECEIVED SIGNAL 12' 12
trap 'echo RECEIVED SIGNAL 13' 13
trap 'echo RECEIVED SIGNAL 14' 14
trap 'echo RECEIVED SIGNAL 15' 15
trap 'echo RECEIVED SIGNAL 16' 16
trap 'echo RECEIVED SIGNAL 17' 17
trap 'echo RECEIVED SIGNAL 18' 18
trap 'echo RECEIVED SIGNAL 19' 19
trap 'echo RECEIVED SIGNAL 20' 20
trap 'echo RECEIVED SIGNAL 21' 21
trap 'echo RECEIVED SIGNAL 22' 22
trap 'echo RECEIVED SIGNAL 23' 23
trap 'echo RECEIVED SIGNAL 24' 24
trap 'echo RECEIVED SIGNAL 25' 25
trap 'echo RECEIVED SIGNAL 26' 26
trap 'echo RECEIVED SIGNAL 27' 27
trap 'echo RECEIVED SIGNAL 28' 28
trap 'echo RECEIVED SIGNAL 29' 29
trap 'echo RECEIVED SIGNAL 30' 30

while [ true ]
do
echo $$ - sleep 10
sleep 10
done

I run it and then I send a SIGCHLD to PID process:

kill -18

but the process receives the signal number 26:

RECEIVED SIGNAL 26

whereas if I send another signal, e.g. 1 ,it receives signals 1 and 26

RECEIVED SIGNAL 1
RECEIVED SIGNAL 26

How can I explain this behaviour?

[Dennis Handly]

I can only assume that SIGCHLD is special to the shell and is used for job control and it is none of your business.

What are you trying to do in your loop? Why aren't you doing a wait instead?

[Peter Godron]

Hi,
and welcome to the forums !

When you send a 18 this results in a 26, which is SIGTTIN - Stop tty input for background process, which is correct.

Please also read:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33 on how to reward any useful answers given to your questions.

[Fedele Giuseppe]

If I do

kill -l

I see that signal 26 is SIGCONT ???

[Dennis Handly]

>I see that signal 26 is SIGCONT???

You are correct. (I didn't have my shell when I replied, to check Peter's answer.)

SIGCONT is being delivered by the kernel.
If you want to prove this, try running tusc to see if it is getting a signal.

Testing this on 11.23 and 11.11, I see no indications it ever got signal 18. Hmm, it seems to wait until the sleep timeout.

Looking at tusc, it seems the shell is only getting signal 26. Signal 18 may be blocked?

[Fedele Giuseppe]

I have noticed that also signal 14 has the same behaviour.