2

I'm having an odd problem. I have a server process that gets started with nohup, and persists across logout and re-login just fine. However if I leave myself logged in and then get the "broken pipe" message because my laptop went to sleep I come back to find that the process stopped at approximately the time my laptop went to sleep (hard to verify exactly when that was though). This happens even if I have logged out and logged back in since starting the process.

Why does this happen? I had thought nohup meant it would ignore SIGHUP? Is some other signal being sent? I am aware of screen, but is there a way to avoid this without resorting to running things in screen (which was the previous solution we just moved away from)?

The command in the script that starts the process looks like this...

nohup attivio -cmd start -nodump -project="$ATTIVIO_PROJECT" -node $NODENAME $ATTIVIO_ARGS foo.xml 2>&1 > $LOG_DIR/attivio.console.log &

The script was invoked like this:

source bin/start.sh
Gus
  • 127
  • 2
  • 11
  • Why did you move away from `screen`? It seems like the perfect solution if you need to launch the process interactively. Otherwise, why aren't you running this as a "proper" service? – fission Mar 23 '13 at 04:23
  • This would not solve your problem but `/some/command ... 2>&1 > /log/file` would not work as you expected. Should be `command ... > /log/file 2>&1`. – SF.express Mar 24 '13 at 14:38
  • One thing I'm wondering is if it would help to disown the process? (and how I would get the process number to do so, hopefully without parsing the output of something like ps :) ) – Gus Mar 25 '13 at 22:10
  • @fission the intention is to eventually do that, but this is an interim measure, that hopefully gets us closer to that point than screen did. – Gus Mar 25 '13 at 22:18

1 Answers1

3

The HUP signal is not the only thing that can stop or kill a process when a terminal disconnects. There will be no controlling tty so some program may still fail for that reason. Attempts to output can cause an error. If the program has an active read, it may get an error, too.

These are reasons I do use screen. I see no reason to avoid screen.

Skaperen
  • 1,064
  • 2
  • 11
  • 21
  • I would like the startup script and the manual invocation to eventually be similar (wip...). I don't think screen is a good solution for a startup (init.d) script. I've never had a problem like this when doing /etc/init.d/apache start for example. (when I have some time to put into it I'm meaning to go pick apart an init script and see how they do it, unless someone here shows me the secret). – Gus Mar 25 '13 at 22:15