[ale] After 15 years, Nohup is sttll broken???

[neal at mnopltd.com]

So, about 15 years ago, when we were transitioning from SCO Unix to 
Linux, we noticed that nohup didn't work on long running Progress 
Database jobs.

We would start an update job via nohup, leave, several hours later the 
ssh session would timeout, and at some point the job would get a hangup 
signal and die.  Which is sometimes really annoying if it's a 15 hour 
job.

Our workaround at the time was a script, "mynohup":

#!/bin/bash
set -x
echo "at `date` Starting: $* " >> mynohup.out
echo "$*  >> mynohup.out " | at now
set +x

Which has worked flawlessly for 14.9 years.

Now we are transitioning to new servers, running
2.6.32-696.30.1.el6.x86_64 #1 SMP Tue May 22 03:28:18 UTC 2018 x86_64 
x86_64 x86_64 GNU/Linux

inside VMs, and we experienced some awkwardness with some admin UI which 
had Apache -> PHP -> sh -> sudo - adminuser -> mynohup something.  
Barfing up some messages about tty devices.   I thought of at least 
unwinding the old kluge.

So, I thought, surely this has been fixed now, and tried running a job 
via nohup from an ssh session.

Sure enough, at some point after leaving the office, the DB log 
shows....

[2019/07/30 at 22:07:25.844-0500] P-28382  7: (562)   HANGUP signal 
received.
[2019/07/30 at 22:07:25.847-0500] P-28382  7: (453)   Logout by neal on 
/dev/pts/4.
[2019/07/30 at 22:07:28.241-0500] P-28439  8: (562)   HANGUP signal 
received.
[2019/07/30 at 22:07:28.241-0500] P-28439  8: (453)   Logout by tdiadmin on 
batch.

Wuh? The sole point of nohup is to not get a hangup, and ....????

regards,

Neal