What's the difference between nohup and a daemon?

Question

I was just wondering what the implication is for running a script as a daemon versus using nohup?

I know what the difference is terms of forking processes etc, but what impact does that have on my script?

Answer 1

In UNIX variants, a process is associated with a terminal process (login shell). So when the terminal process exits, the process is halted as well, because of this association. The nohup prevents a process from exiting when the terminal stops.

A daemon or demon is a process that is started by the system when it starts up, it runs till shutdown, no user asked for it explicitly. So by definition it is not part of a user interaction but belongs to the system.

If you have access to the system as a user, you can use nohup. If you are sysadmin, you can install a deamon process. For the process it does not matter.

Answer 2

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 Stevens' 'Advanced Programming in the UNIX Environment' or 'UNIX Network Programming (3rd Edn)', or Rochkind's 'Advanced UNIX Programming' 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.

Answer 3

a daemon cant b initiated while nohup is initiated by d user