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 '14 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 '14 at 12:35
  • Do you control the remote server? Jun 6 '14 at 12:53
  • yes, it's a beaglebone sitting somewhere in my office
    – NotSqrt
    Jun 6 '14 at 12:54

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/dropbear@.service 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 '14 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 '14 at 13:24
  • @NotSqrt Please see the edit to my answer. Jun 6 '14 at 14:11
  • Tested right now, the file I had to edit was /lib/systemd/system/dropbear@.service. It works ! Well done !
    – NotSqrt
    Jun 6 '14 at 14:24

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.