35

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.

Massimo
  • 68,714
  • 56
  • 196
  • 319

7 Answers7

28

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.

Community
  • 1
Massimo
  • 68,714
  • 56
  • 196
  • 319
  • 2
    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
7

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.

Kim
  • 729
  • 1
  • 5
  • 12
4

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.

Jim
  • 576
  • 2
  • 8
  • 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
  • 3
    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
2

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.

Warner
  • 23,440
  • 2
  • 57
  • 69
  • 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
0

If you log out (Ctrl-D or exit), it will continue to run. But if you close the terminal window, the background processes will receive SIGHUP. They will also receive SIGHUP is you lose a connection to a server. The same goes for a shell running locally (except that you can't lose a connection to a local shell).

x-yuri
  • 1,845
  • 1
  • 22
  • 27
0

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.

Community
  • 1
Warner
  • 23,440
  • 2
  • 57
  • 69
  • 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
-1

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.

warren
  • 17,829
  • 23
  • 82
  • 134
  • 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
  • -1 They do not; the answer isn't so simple. I just tested a simple shell script that I started in background; it looped and sent output to a temp file. It kept running after I exited the terminal (as seen by `tail -f` of the temp file. This on a CentOS 7.1 machine using bash. – Mike S Oct 21 '15 at 14:00
  • @MikeS - please demonstrate. I have never witnessed the behavior you describe – warren Oct 21 '15 at 14:46
  • @warren - See my answer to http://serverfault.com/questions/117152/do-background-processes-get-a-sighup-when-logging-off/730597#730597 . Note that a number of people claim behavior different than what you describe; indeed, Massimo posted precisely because his process continued. – Mike S Oct 21 '15 at 15:12
  • See also http://stackoverflow.com/questions/21294283/when-did-hup-stop-getting-sent-and-what-can-i-do-about-it/21294799#21294799 – Mike S Oct 22 '15 at 20:45