Why do unix background processes sometimes die when I exit my shell?

Question

I wanted to know why i am seeing a different behaviour in the background process in Bash shell

Case 1: Logged in to Unix server using Putty(SSH)

• By default it uses csh shell
• I changed to bash shell
• typed sleep 2000 &
• press enter

It gave me the job number. Now i killed my session by clicking the x in the putty window Now open another session and tried to lookup the process..the process died.

Case 2:Case 1: Logged in to Unix server using Putty(SSH) By default it uses csh shell

• I changed to bash shell
• vi mysleep.sh
• sleep 2000 & Saved mysleep.sh
• ./mysleep.sh

Diff here is..instead of executing the sleep command directly i am storing the sleep command in a file and executing the file.

Now i killed my session by clicking the x in the putty window Now open another session and tried to lookup the process..the process is still there

Not sure why this is happening. I thought i need to do disown in bash to run the process even after logging out.

One diff i see in the parent process id..In the second case..the parent process id for the sleep 2000 becomes 1. Looks like as soon as process for mysleep.sh died the kernel assigned the parent process to 1.

Answer 1

The difference here is indeed the intervening process. When you close the terminal window, a HUP signal (related to "nohup" as an0nymo0usc0ward mentioned) is sent to the processes running in it. The default action on receiving HUP is to die - from the signal(3) manpage,

 No    Name         Default Action       Description
 1     SIGHUP       terminate process    terminal line hangup

In your first example, the sleep process directly receives this HUP signal and dies because it isn't set to do anything else. (Some processes catch HUP and use it to perform some action, e.g. reread some configuration files)

In the second example, the shell process running your shell script has already died, so the sleep process never gets the signal. In UNIX, every process must have a parent process due to the internals of how the wait(2) family of calls works and indeed processes in general. So when the parent process dies, the kernel gives it to init (pid 1, as you note) as a foster child. Orphan process (on wikipedia) has some more information available about it, also see Zombie process for some additional technical details.