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.

What is the difference between

$ nohup foo

and

$ foo &

and

$ foo &
$ disown
share|improve this question
10  
Wait, you can disown without specifying a PID ? Great! –  ripper234 Nov 12 '10 at 11:20
7  
There is also foo &! which should be equal to disowning it right from the start. –  user4514 Nov 18 '12 at 19:02
10  
Bash does not support &!. –  Jonas Kongslund Jun 3 '13 at 4:35
    
@ripper234 help disown says "Remove jobs from current shell. Removes each JOBSPEC argument from the table of active jobs. Without any JOBSPECs, the shell uses its notion of the current job." –  Dr. Sky Lizard 18 hours ago

2 Answers 2

up vote 35 down vote accepted

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 from 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 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, and 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 NOHUP. It is completely independent from job control and could in principle be used also for foreground jobs (although that's not very useful).
share|improve this answer

Using & causes the program to run in the background, so you'll get a new shell prompt instead of blocking until the program ends. nohup and disown are largely unrelated; they suppress SIGHUP (hangup) signals so the program isn't automatically killed when the controlling terminal is closed. nohup does this when the job first begins. If you don't nohup a job when it begins, you can use disown to modify a running job; with no arguments it modifies the current job, which is the one that was just backgrounded

share|improve this answer
6  
Minor difference between nohup and disown: the disown command will remove it from your jobs list; nohup will not. –  Shawn J. Goff Nov 9 '10 at 16:41
107  
nohup and disown both can be said to suppress SIGHUP, but in different ways. nohup makes the program ignore the signal initially (the program may change this). nohup also tries to arrange for the program not to have a controlling terminal, so that it won't be sent SIGHUP by the kernel when the terminal is closed. disown is purely internal to the shell; it causes the shell not to send SIGHUP when it terminates. –  Gilles Nov 9 '10 at 18:26
15  
@Gilles, your comment is worth an answer of itself. –  lesmana Nov 10 '10 at 18:30
2  
Just a clarification on @ShawnJ.Goff 's comment pertaining to disown removing the job from the jobs list. If you don't specify an option, it does remove it from the jobs list. However, if you specify the -h option, each jobspec is not removed from the table. Instead, it makes it so that SIGHUP is not sent to the job if the shell receives a SIGHUP. –  nojak Nov 13 '13 at 6:54
1  
Just to clarify, using & does not give you a terminal, it detaches stdin from the process and causes it to run in the background, but both stdout and stderr is still attached to the current tty. This means that you may get text from different programs mixed up together, which can be quite annoying if you do gimp & and get lots of GTK+ errors while trying to use that tty for something else. –  Frank Jun 5 at 21:18

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.