3

I'm connecting from my computer to a HP UX B.11.31 system and am running some very lengthy there commands using nohup so I can go to sleep and do something else for a few days while they complete.

Example of such a command:

nohup rsync --rsync-path=/usr/local/bin/rsync -e ssh /data/src usr@target:/data/ >> /data/log/sync.out 2>&1 &

Note: the Rsync command's target is a different HP UX server.

It'll run and run, until my computer somehow gets disconnected from the HP UX system (it's connected through SSH over a VPN over my home connection, and disconnections seem to happen once a day).

If this has happened, I can tail /data/log/sync.out and I'll find:

Killed by signal 1.
rsync error: unexplained error (code 255) at rsync.c(549) [sender=3.0.8]

Someone suggested putting the command in a shell script and running that with nohup instead.

So I did that (with a shebang for #!/usr/bin/bash), and then ran the command as nohup ./auto_rsync.sh > /data/log/sync.out 2>&1 &.

The same thing happened.

The funny thing is that if I simply log out while the command is running by typing exit, the command will keep running. So why is only my disconnect sending SIGTERMs to a process running with nohup?

bluppfisk
  • 151
  • 6
  • I'm not sure I understand the question. You wonder why `rsync` dies when your connection disappears? – Kusalananda Oct 01 '19 at 06:34
  • the connection is between two servers that are definitely up, not between my local computer and the server – bluppfisk Oct 01 '19 at 07:20
  • maybe there is a cron script or similar that kills processes that have run for "too long"? –  Oct 01 '19 at 09:30
  • nope, because when I am not disconnected the process just runs on and on and on and – bluppfisk Oct 01 '19 at 09:31
  • 2
    What makes you think it's specifically the disconnection of your SSH connection that makes `rsync` fail, as opposed to something causing both your SSH connection and the rsync-over-SSH connection between the two servers to fail at the same time? – telcoM Oct 01 '19 at 12:02
  • Because it not only happens with rsync commands. It's also any other command that takes a long time. I can't be sure that it happens when I disconnect, but I notice it happens sometime between being connected and me finding out I'm no longer connected. The disconnect event seems the most likely cause. – bluppfisk Oct 01 '19 at 12:54
  • @bluppfisk non sequitur -- that cron or whatever script may skip processes run by "logged in" users (those it can find with `who` or `w`). Are you the admin on that server? Can you contact the admin? –  Oct 02 '19 at 03:23
  • I can contact the admin but they have no idea either why this is happening. So I end up on stackexchange. – bluppfisk Oct 02 '19 at 08:02

1 Answers1

0

It's been a while since I worked on HP/UX but ssh should still have a ServerAliveInterval option. So add "-o ServerAliveInterval=60" after ssh in your command. Or this option can be made perm in .ssh/config or added to the system ssh config file.

EDIT

It is called something different on HP/UX. I found some documentation.

https://support.hpe.com/hpsc/doc/public/display?docId=c01892997

The following parameters, specified in /etc/opt/ssh/sshd_config, allow for setting the desired inactivity period allowed before the session is terminated.

ClientAliveInterval 300
ClientAliveCountMax 6

The above would send a client alive message every five minutes (300 seconds) and for a maximum of six tries. After 30 minutes of a non-responsive client, the client would be disconnected.

The ClientAliveInterval default value of 0 ensures that this alive interval is disabled by default.

Jeight
  • 2,555
  • 3
  • 19
  • 28
  • thank you for digging this up. However, the problem is not my getting disconnected, it's that a SIGTERM seems to be sent to processes currently running (although not to the shell script itself). The funny part is also that if I manually log out, everything keeps on running smoothly. – bluppfisk Oct 01 '19 at 23:03
  • You should probably be posting errors that you are seeing in "/var/adm/messages" or other logging locations. If the script is running for a while without issues then there is probably something else on the system that is causing the sigterm and not rsync. – Jeight Oct 01 '19 at 23:12
  • yes; it's not just rsync but any long-lasting command that will eventually terminate around the time I get disconnected. I probably should've chosen another command as an example. – bluppfisk Oct 01 '19 at 23:13