Suspended child process exit if parent process exit

Question

I have the following process tree

test1.sh
  \- test2.sh
    \- sleep 600

Normally If I kill the test1.sh process, the child processes test2.sh and sleep 600 will continue running. But If I suspend the sleep 600 process through send signal (SIGSTOP or SIGTSTP), and then kill the test1.sh process, the child test2.sh and sleep 600 will exit. Why?

Here is my test program:

test1.sh

#!/bin/sh

./test2.sh

test2.sh

#!/bin/sh

sleep 600

Test steps:

run test1.sh

$ ./test1.sh
open new console and suspend the child process.

$ kill -19 < sleep pid > or kill -20 < sleep pid >
kill the parent process test1.sh

$ kill < test1.sh pid >

You will find the after step3, the test2.sh and sleep 600 exited.

Bug if I only run step1 and step3, ignore step2, the test2.sh and sleep 600 process will not exit.

Can anyone explain this? Many thanks.

Too bad the another site list doesn't have unix.stackexchange.com . — James Brown

Cristian Ramon-Cortes Cristian Ramon-Cortes · Accepted Answer · 2017-08-03T08:08:04

When you are killing process test1.sh, you leave test2.sh orphan so you need to know what happens with orphan processes in your Operating System.

When process test2.sh is running and his parent dies, the OS moves it to the init process and keeps its execution. So the result is both, test2.sh and sleep processes are still up even if you have killed test1.sh.

When process sleep is stopped (signal 20) and his parent dies, the OS tries to move it to the init process. However, since the process is stopped and there will no longer be any tty capable of resuming it (since its parent has died), the OS may decide to do other things with the process. In your case, it dies with SIGKILL to avoid the problem of many stopped, orphaned processes lying around the system. Since the sleep process have exited, the test2.sh process ends too.

From the GNU man page:

While a process is stopped, no more signals can be delivered to it until it is continued, except SIGKILL signals and (obviously) SIGCONT signals. The signals are marked as pending, but not delivered until the process is continued. The SIGKILL signal always causes termination of the process and can’t be blocked, handled or ignored. You can ignore SIGCONT, but it always causes the process to be continued anyway if it is stopped. Sending a SIGCONT signal to a process causes any pending stop signals for that process to be discarded. Likewise, any pending SIGCONT signals for a process are discarded when it receives a stop signal.

When a process in an orphaned process group (see Orphaned Process Groups) receives a SIGTSTP, SIGTTIN, or SIGTTOU signal and does not handle it, the process does not stop. Stopping the process would probably not be very useful, since there is no shell program that will notice it stop and allow the user to continue it. What happens instead depends on the operating system you are using. Some systems may do nothing; others may deliver another signal instead, such as SIGKILL or SIGHUP. On GNU/Hurd systems, the process dies with SIGKILL; this avoids the problem of many stopped, orphaned processes lying around the system.

By the way, if you are willing to kill them always you can add a trap on the main process to capture signals and exit the children properly.

Suspended child process exit if parent process exit

1 Answers