Terminal Process Management

NOHUP - ignore the HUP (hangup) signal. POSIX Compliant.

When using the command shell, prefixing a command with nohup prevents the command from being aborted automatically when you log out or exit the shell.

DISOWN - relinquish job from shell job management. disown can be used after a command has been launched while nohup must be used before. Not POSIX.

The job remains connected to the terminal but is no longer listed in the job table.

This document will reference the HUP signal. HUP, or SIGNUP (signal hang up) is a signal sent to a process when its controlling terminal is closed.

Different shells also have other methods of controlling and managing SIGHUP, such as the disown facility of ksh. Most modern Linux distributions documentation specify using kill -HUP <processID> to send the SIGHUP signal. HUP or hang up is technically the result of receiving the signal to hang up, or SIGNUP but the two are typically used interchangeably.

From the BASH MAN PAGE: The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

You are advised to be familiar with I/O Redirection: stdin (the keyboard), stdout (the screen), and stderr (error messages output to the screen).

nohup

This is not a stand alone command, but one that is used in conjunction with other commands. Here is an example of how you might execute a shell script that you wish to continue running even if you disconnect the terminal.

nohup sh script.sh &

It may appear you command prompt did not return, try pressing the enter key. The last msg can write over the command prompt. To avoid this you could do this:

nohup sh script.sh &> /dev/null

or

nohup script.sh &> /dev/null

if sh is the default shell such as with Linux.

The use of nohup is not equivalent to a daemon process, as nohup is intended for single uses for a shell process not a system managed process or startup process.

To avoid creating nohup.out you can redirect stdout to another file or create one.

nohup script.sh > script.log &

However, errors will still go to the terminal. To redirect both

nohup script > script.log 2>&1 &

Now you have both errors and output going to that file. ( stdout and stderr ). Or you can have output and errors go to their own file respectively.

nohup ./script > script.log 2> script.errorlog &

Or you can discard all output so nothing is displayed on the terminal and no files are generated from the output of the script.

nohup ./script > /dev/null 2>&1 &

As long as output is redirected nohup will not create the default nohup.out file.

disown

When using disown you will note that a process is removed from the list of jobs in the current interactive shell. Running jobs after starting a background process and running disown will not show that process as a job in the shell.

The dishown -h flag - the job is not removed from the list of jobs.

A process started with nohup ignores HUP regardless of who sends the signal while disown -h doesn't receive an HUP no matter what.

ampersand control operator

In the bash shell the ampersand "&" is a control operator with two common forms, the single "&" and the double "&&" ampersand.

&

When the single & is used at the end of the command line the command is forked to run as a job while the shell returns to zero status (you get the command prompt back). The process will not be detached from the terminal in that if the terminal dies the process will soon follow.

Furthermore, when a single & is placed between commands on the same line it will effectively delimit each command to run at the same time, all kicked off and running while the shell returns to zero status.

&&

Not to be confused with using a single & between commands, the use of the double ampersand "&&" is used to separate commands entered on the same command line however they will NOT be ran all at the same time. The first will run and must exit prior to the next, just as though each was on individual lines in a shell script. If the preceding command fails the next will NOT run.

tip: In case you're using bash, you can use the command shopt | grep hupon to find out whether your shell sends SIGHUP to its child processes or not.

disambiguation

The difference between NOHUP, DISOWN, and &, how they differ and if they can be used together is best explained by anonymous writer celtschk, with the following:

Let's first look at what happens if a program is started from an interactive shell (connected to a terminal) without & (and without any redirection). So let's assume you've just typed foo:

• The process running foo is created.
• The process inherits stdin, stdout, and stderr from the shell. Therefore it is also connected to the same terminal.
• If the shell receives a SIGHUP, it also sends a SIGHUP to the process (which normally causes the process to terminate).
• Otherwise the shell waits (is blocked) until the process terminates.

Now, let's look what happens if you put the process in the background, that is, type foo &:

• The process running foo is created.
• The process inherits stdout/stderr from the shell (so it still writes to the terminal).
• The process in principle also inherits stdin, but as soon as it tries to read from stdin, it is halted.
• It is put into the list of background jobs the shell manages, which means especially:
  • It is listed with jobs and can be accessed using %n (where n is the job number).
  • It can be turned into a foreground job using fg, in which case it continues as if you would not have used & on it (and if it was stopped due to trying to read from standard input, it now can proceed to read from the terminal).
  • If the shell received a SIGHUP, it also sends a SIGHUP to the process. Depending on the shell and possibly on options set for the shell, when terminating the shell it will also send a SIGHUP to the process.

Now disown removes the job from the shell's job list, so all the subpoints above don't apply any more (including the process being sent a SIGHUP by the shell). However note that it still is connected to the terminal, so if the terminal is destroyed (which can happen if it was a pty, like those created by xterm or ssh, and the controlling program is terminated, by closing the xterm or terminating the SSH connection), the program will fail as soon as it tries to read from standard input or write to standard output.

What nohup does, on the other hand, is to effectively separate the process from the terminal:

• It closes standard input (the program will not be able to read any input, even if it is run in the foreground. it is not halted, but will receive an error code or EOF).
• It redirects standard output and standard error to the file nohup.out, so the program won't fail for writing to standard output if the terminal fails, so whatever the process writes is not lost.
• It prevents the process from receiving a SIGHUP (thus the name).

Note that nohup does not remove the process from the shell's job control and also doesn't put it in the background (but since a foreground nohup job is more or less useless, you'd generally put it into the background using &). For example, unlike with disown, the shell will still tell you when the nohup job has completed (unless the shell is terminated before, of course).

So to summarize:

• & puts the job in the background, that is, makes it block on attempting to read input, and makes the shell not wait for its completion.
• disown removes the process from the shell's job control, but it still leaves it connected to the terminal. One of the results is that the shell won't send it a SIGHUP. Obviously, it can only be applied to background jobs, because you cannot enter it when a foreground job is running.
• nohup disconnects the process from the terminal, redirects its output to nohup.out and shields it from SIGHUP. One of the effects (the naming one) is that the process won't receive any sent SIGHUP. It is completely independent from job control and could in principle be used also for foreground jobs (although that's not very useful).