I am facing a rather strange situation:

  • ssh to a beaglebone (details : uname -a = "Linux beaglebone 3.2.34 #1 Wed Nov 21 14:17:11 CET 2012 armv7l GNU/Linux", ssh server : Dropbear sshd v2012.55)
  • launch any kind of process through screen, or nohup or /etc/init.d/
  • logout
  • re-ssh into it
  • observe that the process is no longer there..

When using a second ssh connection, I can observe that the launched process is killed at the disconnection.

I've seen posts like What exactly determines if a backgrounded job is killed when the shell is exited, or killed?, but still can't understand this behaviour, which is clearly not the way screen and other disowned processes are supposed to work.

$ shopt huponexit
huponexit       off

I had to resort to using cron commands to persist the process

Why are detached processes killed at disconnection ?

Do you see other things to look for ?

  • Have you tried disown? Jun 6, 2014 at 12:29
  • yes : tried cmd; ctrl+z; bg; disown, jobs gives an empty list, but it still exhibits the same behaviour..
    – NotSqrt
    Jun 6, 2014 at 12:35
  • Do you control the remote server? Jun 6, 2014 at 12:53
  • yes, it's a beaglebone sitting somewhere in my office
    – NotSqrt
    Jun 6, 2014 at 12:54

1 Answer 1


It seems strange nohup does not work, but that can easily be put to test, as follows:

  { sleep 999; echo $? > exitcode ; } &
  fuser -1 -k /bin/sleep
  expr $(cat exitcode) - 128

This will print the return code minus 128, which is exactly the number of the signal that killed it. You can list them simply by doing:

  kill -l 

Now try this instead:

  rm exitcode
  { nohup sleep 999; echo $? > exitcode; } &
  fuser -1 -k /bin/sleep
  ls -l exitcode

If nohup works, at this point you will be told that there is no such file. You can double-check this by doing:

  fuser -15 -k /bin/sleep
  expr $(cat exitcode) -128

and finding this value to be 15.


Your last comment was quite revealing: it means the SIGHUP is not sent to the process (sleep, in this case) but directly to your shell. This can be done ony by Dropberar, of course. A little research showed that Dropbear does indeed kill all user processes at logoff.

You can turn this annoying feature by adding the line


at the end of the Service stanza in /lib/systemd/[email protected] file. Then either reboot or restart Dropbear.

  • For the first sleep without nohup, exitcode - 128 gives HUP as expected. For the second sleep with nohup, the file is indeed absent , and after the kill exitcode - 128 gives 15 as expected.
    – NotSqrt
    Jun 6, 2014 at 13:22
  • but if I don't kill the second sleep that was launched with nohup, and logout and re-log in, the sleep has been killed.. and there is no exitcode file ..
    – NotSqrt
    Jun 6, 2014 at 13:24
  • @NotSqrt Please see the edit to my answer. Jun 6, 2014 at 14:11
  • Tested right now, the file I had to edit was /lib/systemd/system/[email protected]. It works ! Well done !
    – NotSqrt
    Jun 6, 2014 at 14:24

You must log in to answer this question.

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