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?

  • I'm not sure I understand the question. You wonder why rsync dies when your connection disappears?
    – Kusalananda
    Oct 1, 2019 at 6:34
  • the connection is between two servers that are definitely up, not between my local computer and the server
    – bluppfisk
    Oct 1, 2019 at 7:20
  • maybe there is a cron script or similar that kills processes that have run for "too long"?
    – user313992
    Oct 1, 2019 at 9:30
  • nope, because when I am not disconnected the process just runs on and on and on and
    – bluppfisk
    Oct 1, 2019 at 9: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 1, 2019 at 12:02

1 Answer 1


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.


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


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.

  • 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 1, 2019 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 1, 2019 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 1, 2019 at 23:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .