nohup is a POSIX command to ignore the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. The HUP (hangup) signal is by convention the way a terminal warns depending processes of logout.
nohup is most often used to run commands in the background as daemons. Output that would normally go to the terminal goes to a file called nohup.out if it has not already been redirected. This command is very helpful when there is a need to run numerous batch jobs which are inter-dependent.
nohup is a low-level utility simply configuring a command to ignore a signal. As seen below, nohup is very far from being a full-featured batch system solving all the problems of running programs asynchronously.
Contents |
The first of the commands below starts the program abcd in the background in such a way that the subsequent logout does not stop it.
$ nohup abcd & $ exit
Note that these methods prevent the process from being sent a 'stop' signal on logout, but if input/output is being received for these standard IO files (stdin, stdout, or stderr), they will still hang the terminal.[1] See Overcoming Hanging, below.
nohup is often used in combination with the nice command to run processes on a lower priority.
$ nohup nice abcd &
Some shells (e.g. bash) provide a shell builtin that may be used to prevent SIGHUP being sent or propagated to existing jobs, even if they were not started with nohup. In bash, this can be obtained by using disown -h job; using the same builtin without arguments removes the job from the job table, which also implies that the job will not receive the signal. Before using disown on an active job, it should be stopped by Ctrl-Z, and continued in the background by the bg command.[2] Another relevant bash option is shopt huponexit, which automatically sends the HUP signal to jobs when the shell is exiting normally.[3]
The AIX and Solaris versions of nohup have a -p option that modifies a running process to ignore future SIGHUP signals. Unlike the above-described disown builtin of bash, nohup -p accepts process IDs.[4][5]
Note - Nohuping backgrounded jobs is typically used to avoid terminating them when logging off from a remote SSH session. A different issue that often arises in this situation is that ssh is refusing to log off ("hangs"), since it refuses to lose any data from/to the background job(s).[6][7] This problem can also be overcome by redirecting all three I/O streams:
nohup ./myprogram > foo.out 2> foo.err < /dev/null &
Also note that a closing SSH session does not always send a HUP signal to depending processes. Among others, this depends on whether a pseudo-terminal was allocated or not.[8]
There are other ways to accomplish the ability to keep a program running after the user has been logged out. For example, the program could be run inside a GNU Screen-style screen multiplexer. The screen can be then detached. GNU Screen maintains the illusion that the user is always logged in, and allows the user to reattach at any time. This has the advantage of being able to continue to interact with the program once reattached (impossible with nohup alone). A related alternative would be to run the program in a 'detachable' graphical session such as that provided by VNC.
Another possibility would be to use setsid which will run a program in a new session. It is also possible to use 'dislocate' to achieve this effect.
Under Debian, it is possible to use the following command to daemonise a process: /sbin/start-stop-daemon
Another way to avoid the process being bound to a terminal is to have the at daemon run it, as for example with echo command | at now.
|
||||||||||||||||||||||||||||||||