Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

First this question is related but definitely not the same as this very nice question:

Difference between nohup, disown and &

I want to understand something: when I do '&', I'm forking right?

Is it ever useful to do "nohup ... &" or is simply & sufficient?

Could someone show a case where you'd be using '&' and still would want to use 'nohup'?

share|improve this question
    
Have you read the accepted answer and its comment thread? They do explain what nohup does. What part has you confused? –  Gilles Feb 24 '12 at 18:49
    
@Gilles: it may be obvious to you, because you happen to be familiar with these things (seen your rep)... However, for a start, the accepted answer in the link I did put to does not say a word about using both nohup and '&'... I'm pretty sure my question is clear enough and different enough from the other, and two great answers here seems to prove that ; ) Also, are you really implying I did took the pain to link to another question, but without reading the accepted answer!? –  Cedric Martin Feb 28 '12 at 16:12
add comment

2 Answers 2

up vote 13 down vote accepted

First of all, every time you execute a command, you shell will fork a new process, regardless of whether you run it with & or not. & only means you're running it in the background.

Note this is not very accurate. Some commands, like cd are shell functions and will usually not fork a new process. type cmd will usually tell you whether cmd is an external command or a shell function. type type tells you that type itself is a shell function.

nohup is something different. It tells the new process to ignore SIGHUP. It is the signal sent by the kernel when the parent shell is closed.

To answer your question do the following:

  1. run emacs & (by default should run in a separate X window).
  2. on the parent shell, run exit.

You'll notice that the emacs window is killed, despite running in the background. This is the default behavior and nohup is used precisely to modify that.

Running a job in the background (with & or bg, I bet other shells have other syntaxes as well) is a shell feature, stemming from the ability of modern systems to multitask. Instead of forking a new shell instance for every program you want to launch, modern shells (bash, zsh, ksh, ...) will have the ability to manage a list of programs (or jobs). Only one of them at a time can be at the foreground, meaning it gets the shell focus. I wish someone could expand more on the differences between a process running in the foreground and one in the background (the main one being acess to stdin/stdout).

In any case, this does not affect the way the child process reacts to SIGHUP. nohup does.

share|improve this answer
    
+1 to both of you for the great answers... But I'm still confused... I tried that before answering my question: maybe my (very old) Debian Linux setup isn't correctly configured but if I "emacs &" and then type "exit", only my xterm exits: emacs stays there. –  Cedric Martin Feb 24 '12 at 15:15
    
Emacs is complicated enough that it may handle SIGHUP on its own. It's only by default that processes exit on SIGHUP. A lot of 'daemon' programs like ntpd or inetd will re-read their configuration on SIGHUP instead of exiting. I'm a vim guy myself, so I don't have much experience with any emacs. –  Bruce Ediger Feb 24 '12 at 16:58
2  
There's nothing special about emacs. A shell typically sends SIGHUP to its child processes when the shell itself receives SIGHUP, not when the shell exits normally. bash has an option huponexit that causes it to send SIGHUP to children when it exits, but it's not enabled by default. gnu.org/software/bash/manual/bashref.html#Signals –  Keith Thompson Feb 24 '12 at 19:28
add comment

Is it ever useful to do "nohup ... &" - yes. If you just start a process "in the background" with '&', that new process still has membership in the original shell's "process group". If that shell or the process group gets certain signals (SIGHUP, for example), by default they exit. This means that if you run a process with '&' from a shell started by an xterm, or rxvt or some other windowing terminal emulator, when you close the window, the background process gets a SIGHUP. Most casually-written code does not handle SIGHUP, and therefore exists.

If you do "nohup ... &", the nohup command sets SIGHUP to ignored, and then execs the command. That newly exec'ed command keeps the signal mask that nohup setup, unless the command does some signal handling itself. If you close the xterm or rxvt or whatever, the kernel delivers SIGHUP to the command's process, which is ignored. It keeps running.

Doing a nohup on a command allows it to keep running after you close the xterm, or you log off.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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