What are the differences between

$ nohup foo


$ foo &


$ foo & 
$ disown
  • 56
    There is also foo &! which should be equal to disowning it right from the start.
    – user4514
    Commented Nov 18, 2012 at 19:02
  • 42
    Bash does not support &!. Commented Jun 3, 2013 at 4:35
  • 2
    You can also use set -m to enable job control. See unix.stackexchange.com/questions/196603/…
    – Adam D.
    Commented Jan 18, 2016 at 6:31
  • 3
    Given the age of this question+upvotes I think it worth mentioning : all these are aspects and/or low-tech ways if daemonizing a process. Today, post systemd, a more proper way of daemonizing will usually involve a systemd unit
    – Rusi
    Commented Dec 5, 2019 at 9:50
  • 6
    "Daemonizing" is one purpose, but there's also the scenario where someone might need to kick off a long-running process and ensure it doesn't get killed when they close their laptop/lose their hotspot/etc, e.g. long-running build, data migration, web crawling, etc Commented Jan 15, 2020 at 18:49

6 Answers 6


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 or gets stopped.

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).
  • 18
    +1 Thanks. What happens when using disown, nohup and & together then?
    – Tim
    Commented Apr 2, 2015 at 14:27
  • 33
    If you use all three together, the process is running in the background, is removed from the shell's job control and is effectively disconnected from the terminal.
    – celtschk
    Commented Apr 2, 2015 at 15:46
  • 4
  • 8
    Maybe worth including (foo&) subshell
    – jiggunjer
    Commented Aug 25, 2016 at 12:32
  • 11
    As noted at unix.stackexchange.com/questions/446211 , the received wisdom that nohup disconnects from the controlling terminal is wrong. nohup closes some standard I/O streams and opens them elsewhere. It does not change session, attempt to affect the session's connection to a controlling terminal, or deal in process groups.
    – JdeBP
    Commented May 29, 2018 at 8:14

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

  • 14
    Minor difference between nohup and disown: the disown command will remove it from your jobs list; nohup will not. Commented Nov 9, 2010 at 16:41
  • 221
    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. Commented Nov 9, 2010 at 18:26
  • 29
    @Gilles, your comment is worth an answer of itself.
    – Lesmana
    Commented Nov 10, 2010 at 18:30
  • 6
    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. Commented Nov 13, 2013 at 6:54
  • 5
    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
    Commented Jun 5, 2014 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.

In all the cases below I execute like this:



/opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard &
sleep 100

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

nohup .. &

nohup /opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard &
sleep 100

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

& disown

/opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard & disown
sleep 100

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

setsid .. &

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

  • 7
    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
    Commented Mar 21, 2017 at 20:58
  • 4
    For me, with nohup ⟨command⟩ & disown the created process does not stop on Ctrl+C.
    – k.stm
    Commented Jun 27, 2018 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
    Commented Jun 28, 2018 at 13:29
  • @MarinosAn Yes, I did. I ran nohup soffice & and pressed Ctrl+C. Nothing happened, as expected.
    – k.stm
    Commented Jul 5, 2018 at 10:58

Short answer:

  • use & when you want your command to run in the background, so you can run the next one without waiting for it to finish
  • use nohup if you want your command to ignore the SIGHUP signal, so when you close the terminal or log out from ssh session the process keeps running
  • use disown if you forgot to run the command with nohup and want to log out without killing the process (it will disown all processes in the background). To put a process in the background and disown it:
    1. Ctrl+Z to pause process
    2. bg to put stopped process to the background
    3. disown to make process ignore terminal termination
  • for the last disown case - even though the process is disowned and run in bg, is not the program still attached to stdout/stderr of the terminal. So when the terminal gets exited or killed, won't the program stop as it's std*** connections are lost
    – samshers
    Commented Dec 27, 2021 at 7:15

See also the daemonize(1) utility, which handles all of the chores about running a "true background" process. As of its docs:

daemonize runs a command as a Unix daemon. As defined in W. Richard Stevens' 1990 book, Unix Network Programming (Addison-Wesley, 1990), a daemon is “a process that executes `in the background' (i.e., without an associated terminal or login shell) either waiting for some event to occur, or waiting to perform some specified task on a periodic basis.” Upon startup, a typical daemon program will:

  • Close all open file descriptors (especially standard input, standard output and standard error)
  • Change its working directory to the root filesystem, to ensure that it doesn't tie up another filesystem and prevent it from being unmounted
  • Reset its umask value
  • Run in the background (i.e., fork)
  • Disassociate from its process group (usually a shell), to insulate itself from signals (such as HUP) sent to the process group
  • Ignore all terminal I/O signals
  • Disassociate from the control terminal (and take steps not to reacquire one)
  • Handle any SIGCLD signals

Most programs that are designed to be run as daemons do that work for themselves. However, you'll occasionally run across one that does not. When you must run a daemon program that does not properly make itself into a true Unix daemon, you can use daemonize to force it to run as a true daemon.

It superseeds all of the &/nohup/disown mess.


& puts the job in the background, i.e. makes it block input from the shell, and makes the shell not wait for its completion.

nohup and disown both can be said to suppress stdin from the terminal and SIGHUP, but in different ways. nohup works when the job is initialized, disown works after the fact.

nohup also redirects stderr to stdout and stdout to $HOME/nohup.out. It does not block other signals being sent indirectly from the original shell.

disown does not redirect stdout or stderr. It simply removes the process from the shells job table, so no signals will be indirectly sent to the process from the original shell.

  • Therefore, a nohup process may still receive SIGTERM, SIGKILL, SIGINT, SIGQUIT, etc. from the parent process. This may result in a process exiting when you expect it to not to.
    – mcmah309
    Commented Dec 23, 2023 at 2:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .