1

In previous jobs and experiences, I used screen or nohup to run my long running jobs from my terminal screen. Most, if not all of my previous jobs' servers dropped you if it didn't detect any activity after X amount of time. Even if I had set ServerKeepAlive and other settings in my .ssh/config file, in some cases I still got booted, probably because the server ignored my settings. I used nohup once or twice but I mainly use screen to keep my process running.

Yesterday, I forgot to run my command with screen or nohup. I got booted off and I thought I was hosed. However, for some reason, the process was still running, even after several hours. I typed in ps -ef | grep myprocname and it was there until it was completed. I didn't run my process in the background (not sure if that makes a difference). I just type in ./script.sh and let it run.

What setting on the server allowed this fortuitous event to occur? I think the remote server is running Centos 6.4. Is this a Centos 6.4 thing, to not terminate processes when the parent process (in this case my ssh connection/shell) is killed? Do I need to go back to reading a Unix/Linux book since this is an easy question? Do I have my basic Unix facts wrong (about the parent process)? Did I get lucky?

migrated from superuser.com Feb 7 '14 at 23:55

This question came from our site for computer enthusiasts and power users.

  • 3
    If the shell closes it's childs receive a hangup signal. If the child ignores it (which is one of the things nohup does), it keeps running and is inherited by the init process. The new parent pid is 1. I can not say anything useful about your particular case though. – mugen kenichi Jan 21 '14 at 20:14
  • @matthiaskrull, thx for the unix tutorial. You learn something new everyday =) I guess I got lucky then, unless this is something new with Centos 6.4 where nohup is run by default? I'll see if I can find who to ask around here, or I'll keep hoping someone in the community knows what might have happened. – Classified Jan 22 '14 at 0:20
  • 2
    I have been wondering about this as well, I've noticed that on some systems my jobs survive log out and on others they don't. If you don't get an answer here after a few days, you might want to consider flagging this for moderator attention (use the link under the tags) and asking to migrate to Unix & Linux where you get more hardcore *nix geeks. – terdon Jan 25 '14 at 19:56
  • @terdon, thx for confirming i'm not crazy =) can i just open a new question there and leave this here too or that's not how forums on stackexchange work? – Classified Jan 26 '14 at 1:09
  • 4
    No, cross-posting tends to be frowned upon unless you can give the Q a different twist, more appropriate to each target site. This ! is on-topic on both sites so it's up to you where you want to leave it – terdon Jan 26 '14 at 19:50
2

This will not be answering your question in particular but be some general information on system behavior relevant to your problem and may help to understand how to better control what is happening.

In UNIX and UNIX-like systems processes started inside a shell will be child processes of that shell. If a shell closes (for example by disconnecting) or dies its child processes will receive a hangup signal (SIGHUP) and the child processes will be inherited by init, the first process, and thus will have the parent pid 1 like daemonized processes.

The child can implement a handler and it can be decided programatically what action to take. Usually the child will quit on hangup in shells.

To prevent that or take a different action you can use a signal handler(see trap in bash):

#!/bin/bash

trap '' HUP

# some long running action here

This will ignore the HUP signal. You can add some operations as well like this:

#!/bin/bash

on_hangup() {
    echo "Cought SIGHUP"
    # more commands/action
    # like redirection stdout to preserve output
    # or exit
}

trap 'on_hangup' HUP

# long running stuff here
  • thx for the code and tip. this is cool stuff i'd never learned before – Classified Jan 22 '14 at 21:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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