Linux has a few options on getting a command to run in background and if desired keep it running even if there is a terminal session interruption. So what’s the difference and why you may use one vs. the other? To understand when and why lets take a look at what each once does in a nutshell. We will use a bogus command of “foo” in the examples:
- nohup: nohup takes a command or script and keeps it separate from the terminal. It will also create a nohup.out file within the directory where you ran nohup. This will have the output of the command/script you ran. You would use this with your initial command/script.
- example: # nohup foo
- “&” and “bg“: This is used to launch a command in the background. If a redirect of standard out is not down you will still see any output of the command. You can circumvent this by using “2>&1” at the end of the command.
- example: # foo &
- disown: Allows you to remove a job for the job list so a SIGHUP form the shell wont affect it. This is great if you have a command running and want to keep it going and not worry about it closing for a SIGHUP. However, if you close the terminal session it will also kill your disowned job. Here in lies the big difference between nohup. Since nohup detached it self you can close your terminal session and it will continue to run.
Okay we have an idea what these are but how to use them. There are somethings that are specific to each, not only how to launch it but how to manage it.
Lets say we have a command called “foo” and we want to run it with no interruption to its task even if the terminal session closes. We proceed the command with “nohup”. We can always view the standard output by using tail to view the nohup.out file. This file will be created within Louisethe working directory:
Simple loop # vi foo while : do ls sleep 60 done
Run in background # nohup ./foo & nohup: ignoring input and appending output to 'nohup.out' #
Run in Background Usage
If you want to be able to have a process and be able to interrupt it while its running in background then this is what you would use.
Run in background # ./foo & Already running in foreground, put in background. Use <CTRL-Z> to put in background # ./foo # <CTRL-Z> + Stopped ./foo Check Process # ps -ef |grep foo |grep -v grep andy 31474 31423 0 11:05 pts/3 00:00:00 /bin/sh ./foo Check Job # jobs + Stopped ./foo Now lets run the stopped job in the background Check Job # jobs + Stopped nohup ./foo Background the job # bg 1 + nohup ./foo & # jobs + Running nohup ./foo &
So it doesn’t matter if its just a program, script or command you can use “&” or “bg”. The same holds true for “nohup”.
Lets say we want to take a program that’s already running in the background. Instead what we did previously we do not want SIGHUP to interrupt it but we are okay if it closes with a terminal session closure. We will use “disown” in the case:
Check Job # jobs + Running nohup ./foo & # disown %1 # jobs #
What happened? Why isn’t my job showing up? This is because “disown” separates it from the terminal session. In order to see if its still running we need to use the “ps” command:
# ps -ef |grep foo|grep -v grep andy 31579 31423 0 11:11 pts/3 00:00:00 /bin/sh ./foo Now if we wanted to would could kill the process, which by the way is one way we would kill a "nohup" process. # kill -9 31579 # ps -ef |grep foo|grep -v grep #
Full disclosure the next sections verbiage is from celtschk @ Unix Stack Exchange
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.
disownremoves 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.
nohupdisconnects the process from the terminal, redirects its output to
nohup.outand 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).