2

For what reason(s) would nohup not work on a specific in-house developed process?

I'm using it as follows:

/usr/bin/nohup process_a &

I can close the terminal where it was executed and see that it is still running via ps. However, after logging out and back in again the process is no longer running.

I can run the same nohup command on a different in-house developed process_b and logging out and back in does not end the process. It is still running.

I'm wondering what could be "special" about process_a such that it does not survive logging out and back in again. Both process a and b open a TCP server socket and also have open file descriptors for logging.

I've tried using bash, tcsh, and zsh shells, all with the same results.

For what reason(s) would one process running under nohup survive logging out/in and another would not? I'm assuming there's something in the code that the developers can change.

We're running RHEL 6 in a fairly restrictive environment (screen, tmux, etc. are not available alternatives).

UPDATE:

process_a survives the following

kill -s HUP PID

so SIGHUP appears to be successfully handled via nohup in this instance. It still dies at logout though.

Improve this question
12
  • Is there any use of /dev/tty in process_a?
    – icarus
    Feb 10, 2020 at 4:25
  • No explicit use of /dev/tty by the process
    – RudolfSchmidt
    Feb 10, 2020 at 20:00
  • @icarus: It wouldn’t have to be /dev/tty, would it? A reference to stdout or stderr could cause a problem, right? … … … … … … … … … … … … … … … … … … RudolfSchmidt: What happens if you do nohup process_a > /dev/null 2>&1, and then logout and login again?
    – G-Man Says 'Reinstate Monica'
    Feb 10, 2020 at 22:25
  • G-Man: logout/login = it dies. It still survives the kill -HUP though. I verified that fd's 0, 1, and 2 all point to /dev/null in /proc/PID/fd.
    – RudolfSchmidt
    Feb 10, 2020 at 22:50
  • @G-ManSays'ReinstateMonica' the versions of nohup that I know about redirect stdout and stderr to the file nohup.out if they are still connected to the terminal.
    – icarus
    Feb 11, 2020 at 1:52

2 Answers 2

Reset to default
2

If the code of process_a explicitly catches SIGHUP (the hangup signal) or resets it to the default handler (i.e., none; i.e., exit), that would explain the behavior you are seeing.  Ask the developers to search the code for SIGHUP and see what it is doing.

You might be able to diagnose this better if you can run strace on the program, but, since you have “a fairly restrictive environment”, strace probably isn’t available.  You may be able to test more quickly and generate more actionable forensics if you

  1. Start the process (nohup process_a &),
  2. note the PID that is reported,
  3. wait a few seconds or minutes,
  4. verify that the process is running with the known PID (e.g., with ps),
  5. do kill -HUP PID,
  6. recheck the process, and maybe
  7. wait a few seconds or minutes and recheck the process again.
Improve this answer
2
  • The code base does not do anything with SIGHUP.
    – RudolfSchmidt
    Feb 10, 2020 at 19:58
  • The process survives kill -HUP PID. strace is not available currently, but I am going to request it. Thanks for the suggestions.
    – RudolfSchmidt
    Feb 10, 2020 at 19:59
0

The specific reason that this process did not survive log out/in while running under nohup was that it utilized Motif. Even though in our environment for this process the GUI was not being invoked/realized, the code ultimately used XtAppMainLoop in its main() (c code). Perhaps the Motif libraries do something with the SIGNALS.

Additional reasons, as suggested in the other answers/comments:

The process explicitly catches/resets SIGHUP

The process utilizes tty device(s)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .