What are the differences between

$ nohup foo

and

$ foo &

and

$ foo & 
$ disown
  • 40
    Wait, you can disown without specifying a PID ? Great! – ripper234 Nov 12 '10 at 11:20
  • 31
    There is also foo &! which should be equal to disowning it right from the start. – user4514 Nov 18 '12 at 19:02
  • 24
    Bash does not support &!. – Jonas Kongslund Jun 3 '13 at 4:35
  • 14
    foo & disown to disown immediately. – ctrl-alt-delor Jul 13 '16 at 22:16
  • 6
    I'd love to see a mention of setsid, and how it relates to disown and nohup – YoungFrog Dec 1 '16 at 9:10
up vote 464 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 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).

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

  • 8
    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
  • 183
    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
  • 27
    @Gilles, your comment is worth an answer of itself. – lesmana Nov 10 '10 at 18:30
  • 5
    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
  • 4
    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 '14 at 21:18

Here is my experience trying to run soffice in the background, following a non-terminating command (e.g. tail). For this example I will use sleep 100.

&

#!/bin/bash
/opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard &
sleep 100

I see soffice logs / by pressing Ctrl-C soffice stops

nohup .. &

#!/bin/bash
nohup /opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard &
sleep 100

I don't see soffice logs / by pressing Ctrl-C soffice stops

& disown

#!/bin/bash
/opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard & disown
sleep 100

I see soffice logs / by pressing Ctrl-C soffice stops

setsid .. &

#!/bin/bash
setsid /opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard &
sleep 100

I see soffice logs / by pressing Ctrl-C soffice DOES NOT STOP

To save space:
nohup setsid .. : does not show logs / soffice DOES NOT STOP on Ctrl-C
nohup with & disown at the end : does not show logs / soffice stops on Ctrl-C

  • 2
    While I appreciate the effort of mentioning setsid and showing what​ happens in that specific situation, I'd like to see a more thorough answer. In particular the difference and similarities of each solution, both visible (what happens when close the shell or the terminal, where does the output go,...) and invisible (how things are done under the hood and their implications). The accepted answer is a nice base for that. – YoungFrog Mar 21 '17 at 20:58
  • 1
    @YoungFrog I will agree on this! – Marinos An Mar 21 '17 at 21:06
  • For me, with nohup ⟨command⟩ & disown the created process does not stop on Ctrl+C. – k.stm Jun 27 at 20:23
  • @k.stm Did you try soffice? soffice command seems to have something different. So I considered adding it here as a rule exception. e.g. when using: nohup .. & , pressing Ctrl-c normally does not cause the command to stop, but with soffice it does. I wait until someone steps on this and explains why this happens with soffice :) – Marinos An Jun 28 at 13:29
  • @MarinosAn Yes, I did. I ran nohup soffice & and pressed Ctrl+C. Nothing happened, as expected. – k.stm Jul 5 at 10:58

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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