Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Asking this after a prolonged discussion with a coworker, I'd really like a clarification here.

I launch a background process, either by appending "&" to the command line or by stopping it with CTRL-Z and resuming it in background with "bg". Then I log out.

What happens?

We were quite sure it should have been killed by a SIGHUP, but this didn't happen; upon logging in again, the process was happily running and pstree showed it was "adopted" by init.

Is this the expected behaviour?

But then, if it is, what's the nohup command's purpose? It just looks like the process isn't going to be killed anyway, with or without it...


Edit 1

Some more details:

  • The command was launched from a SSH session, not from the physical console.
  • The command was launched without nohup and/or &; it was then suspended with CTRL-Z and resumed in background with bg.
  • The ssh session did not drop. There was an actual logout ("exit" command).
  • The process was a scp file copy operation.
  • Upon logging in again, pstree showed the process running and being child of init.

Edit 2

To state the question more clearly: will putting a process in background (using & or bg) make it ignore SIGHUP, just like the nohup command does?


Edit 3

I tried manually sending a SIGHUP to scp: it exited, so it definitely doesn't ignore the signal.

Then I tried again launching it, putting it in the background and logging off: it got "adopted" by init and kept running, and I found it there when logging back on.

I'm quite puzzled now. Looks like no SIGHUP was sent at all upong logging off.

share|improve this question
    
I didn't see any mention of console I/O in there, which will also trip things up. Did you divert things i.e. 1>/dev/null 2>&1 for bash, etc.? –  Avery Payne Feb 24 '10 at 2:44
    
No, I didn't. SCP of course didn't require standard input... and standard output didn't seem to be an issue. –  Massimo Feb 24 '10 at 6:51
    
Whether or not your shell is executed as a login shell changes performance, which may be the case here. –  Warner Feb 24 '10 at 22:45
    
Done some other tests; I summed it up here: serverfault.com/questions/117152. –  Massimo Feb 26 '10 at 13:20
add comment

6 Answers 6

up vote 10 down vote accepted

Answer found.

For BASH, this depends on the huponexit shell option, which can be viewed and/or set using the built-in shopt command.

Looks like this options is off by default, at least on RedHat-based systems.

More info on the BASH man page:

The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.

share|improve this answer
1  
That's a stupid default, but my guts tell me it's a RH fault rather than bash. Btw, with zsh you can use &! as a shortcut to disown, and processes forked with & do get sighup. –  Jürgen Strobel Sep 19 '11 at 13:05
add comment

I agree with Warner and just want to add that you can keep the shell from sending SIGHUP with the builtin "disown" command. The bash man page contains a good description.

share|improve this answer
    
Why that downvote?!? –  Massimo Feb 24 '10 at 9:20
    
Voted up. He is right. –  Warner Feb 24 '10 at 14:58
add comment

When you fork a process into the background it will still be the child process from the shell executing it.

All child processes running under a shell are sent a SIGHUP upon exit. Performance varies slightly depending upon the exact situation, which is detailed verbosely in bash's manpage. Other shells likely have similar descriptions.

Apache, and other daemons, typically reload configuration on SIGHUP. Userspace utilities often die. Application performance linked to signals can be unique to the application.

share|improve this answer
    
So the process should just have received a SIGHUP in this case, right? Maybe it just ignored it, I'll check. –  Massimo Feb 23 '10 at 21:43
    
Yes, exactly. That's what I believe the situation to be. If you really doubt the documented performance, you could hack out a little script to trap the signal and log it. –  Warner Feb 23 '10 at 21:45
add comment

You can use the command nohup to launch the command and redirect output into a nohup output file. From the nohup man page:

nohup - run a command immune to hangups, with output to a non-tty

The other option is to use the screen command. The benefit of using screen is that you can reconnect to the process later.

share|improve this answer
    
Why the downvotes? Using nohup and screen are perfectly acceptable ways to avoid killing a process on logout. There are others, but both of these work. What's the deal? –  Jim Feb 24 '10 at 15:41
    
I think it's a great point, but the Q is about why his processes aren't being killed NOT "how to keep them from getting killed". –  CarpeNoctem Feb 26 '10 at 13:36
add comment

If you didn't launch the command via a tool like screen, then when the session ends, so do all jobs/tasks associated with that session.

share|improve this answer
    
That's exactly what I was thinking, except... they just didn't. –  Massimo Feb 23 '10 at 21:42
    
they have every time I've done what you've described... maybe it depends on the shell you use? –  warren Feb 23 '10 at 22:32
add comment

What was the process? The performance described in the earlier posting1 was accurate.

Certain script functions and processes can trap signals. while loops can run away like crazy.

See:

SSH session drops - Does the command continue executing?

Edit 1 at 4:22PM

From the bash manpage:

The shell exits by default upon receipt of a SIGHUP.   Before  exiting,
an  interactive  shell  resends  the  SIGHUP  to  all  jobs, running or
topped.

Initial research1 is showing that OpenSSH probably ignores SIGHUP, maybe more signals.

share|improve this answer
    
That post actually ispired me to ask the question. For details, see edit above. –  Massimo Feb 23 '10 at 21:21
2  
The answers in the other thread make it sound like you need to read up on the SCP command you're using and see how it responds to SIGHUP –  mfinni Feb 23 '10 at 21:21
    
And 'nohup' is for commands that you know will die with a SIGHUP and you don't want them to, I guess. –  mfinni Feb 23 '10 at 21:22
    
The man page just doesn't tell it; I'll try killing it -HUP tomorrow... –  Massimo Feb 23 '10 at 21:28
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.