What's the Difference Between Nohup and Ampersand

What's the difference between nohup and ampersand

nohup catches the hangup signal (see man 7 signal) while the ampersand doesn't (except the shell is confgured that way or doesn't send SIGHUP at all).

Normally, when running a command using & and exiting the shell afterwards, the shell will terminate the sub-command with the hangup signal (kill -SIGHUP <pid>). This can be prevented using nohup, as it catches the signal and ignores it so that it never reaches the actual application.

In case you're using bash, you can use the command shopt | grep hupon to find out whether
your shell sends SIGHUP to its child processes or not. If it is off, processes won't be
terminated, as it seems to be the case for you. More information on how bash terminates
applications can be found here.

There are cases where nohup does not work, for example when the process you start reconnects
the SIGHUP signal, as it is the case here.

What are the differences between nohup and bg?

Processes backgrounded with 'bg' are still tied to the shell that launched them and will close when the shell closes. Processes detached with 'nohup' will run even after you log out.

Nohup vs Nohup &

It would be better if you would understand what's going on.

nohup set's the process to ignore HUP signal. That's all. Nothing more nothing less. When does a process receive a HUP signal? Usually when a terminal logouts. And the default action on HUP signal is to terminate.

hitting "CTRL+C" just sends INT signal to the process. The default action (and you can trap "echo something" INT override it too) is to terminate the process.

nohup sh script.sh upon receiving INT signal will terminate (assuming script.sh didn't specially handle the INT signal) as it didn't set up a custom action on receiving a INT signal and it will ignore HUP signal.

The & placed after a command runs it in the background. As a separate process. So sh script.sh & runs sh in the background. The process will still terminate if you send it INT signal, just CTRL+C doesn't send it to that process, but to process that is in foreground. You can send it still using kill command. And the command will still terminate when the terminal exits, when the process receives the HUP signal.

So running nohup sh script.sh & will run the process in the background and ignore the signal that is send when the terminal exits. But still it will terminate on receiving INT signal. Just pressing CTRL+C in terminal will not send it to this process, as shell sends the term signal to the foreground process, not the background one.

What's the difference between nohup and a daemon?

The nohup command is the poor man's way of running a process as a daemon. As Bruno Ranschaert noted, when you run a command in an interactive shell, it has a controlling terminal and will receive a SIGHUP (hangup) signal when the controlling process (typically your login shell) exits. The nohup command arranges for input to come from /dev/null, and for both output and errors to go to nohup.out, and for the program to ignore interrupts, quit signals, and hangups. It actually still has the same controlling terminal - it just ignores the terminals controls. Note that if you want the process to run in the background, you have to tell the shell to run it in the background - at least on Solaris (that is, you type 'nohup sleep 20 &'; without the ampersand, the process runs synchronously in the foreground).

Typically, a process run via nohup is something that takes time, but which does not hang around waiting for interaction from elsewhere.

Typically (which means if you try hard, you can find exceptions to these rules), a daemon process is something which lurks in the background, disconnected from any terminal, but waiting to respond to some input of some sort. Network daemons wait for connection requests or UDP messages to arrive over the network, do the appropriate work and send a response back again. Think of a web server, for example, or a DBMS.

When a process fully daemonizes itself, it goes through some of the steps that the nohup code goes through; it rearranges its I/O so it is not connected to any terminal, detaches itself from the process group, ignores appropriate signals (which might mean it doesn't ignore any signals, since there is no terminal to send it any of the signals generated via a terminal). Typically, it forks once, and the parent exits successfully. The child process usually forks a second time, after fixing its process group and session ID and so on; the child then exits too. The grandchild process is now autonomous and won't show up in the ps output for the the terminal where it was launched.

You can look at Advanced Programming in the Unix Environment, 3rd Edn by W Richard Stevens and Stephen A Rago, or at Advanced Unix Programming, 2nd Edn by Marc J Rochkind for discussions of daemonization.

I have a program daemonize which will daemonize a program that doesn't know how to daemonize itself (properly). It was written to work around the defects in a program which was supposed to daemonize itself but didn't do the job properly. Contact me if you want it - see my profile.

Difference between nohup vs simple output redirect

The difference in the listed approaches depends on the status of huponexit variable in your shell. The status of this variable is obtained by shopt | grep huponexit.

When huponexit is off, the listed approaches are operationally identical -- Both redirect standard output to logfile and continue to run upon exiting the shell.

When huponexit is on, (shopt -s huponexit), the shell sends the hangup (hup) signal to child processes which causes it to terminate. The nohup approach continues to work.

Since you may not always have privileges to control huponexit, the nohup approach is more failsafe for long background jobs.

Difference between nohup vs at now

The difference is that now runs a command that can respond to HUP signal, where as the nohup runs a command that is immune to HUP signal.

---

Related Topics