Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

When I ssh to a server and start a script that is supposed to run for several days, it stops executing some time after I log off. Why? I suppose the server runs 24/7.

And what does screen/tmux do to prevent this from happening?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

From an operating system's point of view, every running program is a process. When the kernel is done initializing it will start one process, mostly init. Whether it is SYSV init or systemd is not relevant for this discussion, one process is started. Every other program is started by another process. This creates a relationship between processes, the starting process (a.k.a. "parent") and the started process (a.k.a. "child"). The kernel is aware of these relations.

When a process exits in linux/unix, the kernel sends to all childprocesses the signal number 15 (SIGTERM). It can be caught by the process and the process should do whatever it has to do to exit in a save way. You may know also know the signal number 9 (SIGKILL). This signal cannot be caught by the process: the kernel exits the process by himself.

See this pstree:

init─┬─acpid
     ├─atd
     ├─cron
     ├─dbus-daemon
     ├─dhclient
     ├─dhcpd
     ├─exim4
     ├─6*[getty]
     ├─lwresd───6*[{lwresd}]
     ├─named───6*[{named}]
     ├─nmbd
     ├─portmap
     ├─rpc.statd
     ├─rsyslogd───2*[{rsyslogd}]
     ├─smbd───2*[smbd]
     ├─sshd───sshd───bash───screen───screen───bash───pstree
     └─udevd───2*[udevd]

You can see that pstree is a childprocess of bash, and bash a childprocess of screen. When I logout from the machine, the bash after sshd exits and the kernel sends a signal 15 to the childprocess screen. BUT, screen doesn't react to this. So screen's new parent process is now process number 1 (init). See in this pstree:

init─┬─acpid
     ├─atd
     ├─cron
     ├─dbus-daemon
     ├─dhclient
     ├─dhcpd
     ├─exim4
     ├─6*[getty]
     ├─lwresd───6*[{lwresd}]
     ├─named───6*[{named}]
     ├─nmbd
     ├─portmap
     ├─rpc.statd
     ├─rsyslogd───3*[{rsyslogd}]
     ├─screen───bash
     ├─smbd───2*[smbd]
     ├─sshd───sshd───bash───pstree
     └─udevd───2*[udevd]

In fact, this is what happens when you detach the screen (ctrl+a - d). So all subprocesses of screen keep running after disconnecting or detaching from screen. When you run a process without screen or tmux, it will get a SIGTERM signal.

share|improve this answer
1  
No, the kernel does not send SIGTERM to the children of a process when it dies. It may send SIGHUP under some circumstances (and it has to do with session handling, not parent-child relationship). It can't see what SIGILL has to do with all that. –  Stéphane Chazelas Dec 9 '13 at 21:44
    
Accepting this as it answers why, but would be nice if someone would correct the mistake. –  The Unfun Cat Dec 10 '13 at 7:10

You need to use the nohup command. A explanation is provided here. Basically it detaches the program you are running from your terminal session it is closed the program does not die with its parent. tmux and screen also detach the programs they run that is why you get the same behavior.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.