1

I'm running KDE Neon which is Ubuntu 18.04 Bionic (LTS) with the latest KDE desktop packages on top of it.

Since upgrading to this from Xenial I have lost the ability for processes to survive SSH session disconnects... specifically nohup, tmux, screen, byobu and all their children are killed when disconnecting.

Here's a simple test to demonstrate the problem

# connect over ssh
cd /tmp
nohup watch date &
ps -ef | grep watch
# disconnect and reconnect
ps -ef | grep watch # process is gone

I tried reverting tmux and byobu to older versions before discovering nohup was also effected. This leads me to believe that it's either SSHd config or systemd.

Apparently systemd decided to change it's default behaviour to nuke all users processes when a user disconnects some time ago. I tried to revert the behaviour by editing /etc/systemd/logind.conf and setting KillUserProcesses=no and then rebooting (service systemd-logind restart didn't work). It didn't work... I'm at my wits end.

Help!

  • Hi Ironstorm, I see is not a single command you can send in background with a "&". Try to set it as a .service following this tread, link: askubuntu.com/questions/919054/… . Let me know if was useful. – NwalmeThule Aug 28 '19 at 20:39
  • @NwalmeThule The & operator sends a process to the background as a job, but it's still owned by the shell (bash) which is in turn owned by SSH, which default configuration says to kill all the child processes on disconnect. – Kristopher Ives Aug 28 '19 at 21:03
  • Does this help unix.stackexchange.com/q/504606/323121 ? – Rusi Sep 5 '19 at 12:46
0

You want to use the setsid command to make it a session leader.

nohup means "no hang up" which for the most part just disconnects the various standard input/output streams, but that process is still "owned" by the bash process which is in turn owned by the SSH process. When you disconnect from SSH, all those child processes go with it.

By using setsid you re-parent the process outside of the scope of SSH.

  • Nope, that's not how it works on RHEL or any other normal Unix-like system... When nohup is run and someone hangs up (disconnects), the process is supposed to continue running with init (pid 1) as the parent. – ironstorm Aug 28 '19 at 21:13
  • There are many implementations of nohup because it's both a command and a bash intrinsic, and ultimately any program can (and some do) go out of their way to reconnect the signals. In either case, setsid will solve these issues by explicitly re-parenting the process to pid 1 instead of relying on it to happen at a later time. – Kristopher Ives Aug 28 '19 at 23:57

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.