Nohup with ampersand & process gets disconnected

Linux and Unix-Like Red Hat
1

For years I have spawned shell scripts with nohup and ampersand and they run whether or not I stay logged in. Recently a client told us that we had to set a keep alive timeout on all of our Redhat 7.6 Linux servers. Our sysadmin set the following parameters in the sshd_config file on all of our Redhat 7.6 servers:

ClientAliveInterval 900
ClientAliveCountMax 0

Now when I try to nohup an Oracle database clone script or some other type of Oracle database shell script, the script tends to die within 15 minutes. If I run the script through crontab it works fine. I have tried running tests where I use disown after spawning a script with nohup and ampersand, but that doesn't seem to help. Since the scripts are using sqlplus, and that is spawning its own process, my assumption is that the parent process is idle, even though the child process is not idle. Hence, the script dies.

I would use crontab, but then I need to remember to take the job out of crontab, otherwise it will continue to run on the schedule that I used. Does anyone have any suggestions on how to run scripts without them being killed by the OS?

Thanks

2

If these programs are opening /dev/tty by themselves, nohup can't stop them from getting the boot. Running from crontab they wouldn't, as opening /dev/tty wouldn't get anything anyway.

I'd be really curious what file descriptors you find open in all PID's owned by you after you do a nohup ./script & disown ; exit , visible in /proc/####/fd. If some database client is grabbing /dev/tty maybe it can be convinced not to do so with a commandline switch.

There's also the "at" daemon if you have it, a kind of cron equivalent for one time tasks which lets you specify something to run at a time in the future.

1 Like
3

You should consider configuring your ssh terminal client to send keep alives.

The way I read your post is that you are remotely logged into a server using ssh and you are having trouble with your ssh terminal being terminated. You have tried to set up keepalives on the server side (sshd); but you have not configured your client to send keep alives.

I used to have this same problem (very annoying) with my MacOS ssh terminals remotely logged into linux servers. Regardless of my settings on the server side, my ssh terminals would time out, annoyingly. I used to use a work-around like "watch /some/changing/logfile.log" and that would insure the terminal remained alive; but I did not like that bandaid (cluttering up my terminals, since I often have four opened at once on the same screen).

Then, I decided to configure my client terminal to send keepalives to the server (in my case MacOS), and since then my client ssh terminals never die, even when logged in for many days with no terminal activity.

What ssh terminal client are you using?

Or, did I completely misunderstand your question, gandolf989?

When you are talking sshd, linux and keepalives, this leads me to think you are remotely logged in to a linux server and you want to keep the ssh session alive. Isn't that right?

1 Like
4

Use screen , just run the script, detach session.

Great tool, written exactly for your use case, and many others.

Hope that helps
Regards
Peasant

1 Like
5

Great advice.

I've never used screen and just installed it and will give it a try.

Thanks!

6

I am not sure what your version of nohup is doing.
Try the following nohup.sh script:

#!/bin/sh
# ignore signals HUP INT QUIT
trap "" 1 2 3
# redirect filedescriptors 0...6
exec "$@" </dev/null >/dev/null 2>&1 3>&1 4>&1 5>&1 6>&1

Then run yourscript with

./nohup.sh yourscript &

--- Post updated at 13:39 ---

BTW screen is also a great collaboration tool. Two and more persons can really share a terminal screen.

1 Like
7

the AT daemon should be a viable option. I just need to look up the syntax.

--- Post updated at 01:22 PM ---

I do use keep alives in my interactive sessions and it works. But this doesn't help when I spawn a process.

--- Post updated at 01:24 PM ---

I like the idea of using screen and I am going to test that. I like that I can go back to a session after the fact and see everything that was there. I just need to figure out how to use it.

--- Post updated at 01:27 PM ---

Cool script. I will have to test it and see how it works. Did you use the Bourne shell for a particular reason?
Why not use the Bash shell? Thanks

8

Portability: /bin/sh is present on every *X OS. (Well, SCO Unix and an old HP-UX might need the workaround ${1+"$@"} for a historic bug with "$@" .)
It works with any compatible shell, too.

9

This script doesn't actually need bash, so it's better to use the more portable /bin/sh. It can be carried to AIX or whatever without compatibility worries.

10

Unfortunately, for backwards compatibility reasons /bin/sh on Solaris systems (at least up until Solaris 11) is a pure 1980's Bourne shell. To get a POSIX conforming shell on Solaris systems, their man pages, indirectly, say to use /usr/xpg4/bin/sh .

11

I tested screen on several servers and it works really well. No problems so far. Thanks.