7

I run a rsync command with nohup in ssh session, but after a while it returns this error:

rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [generator=3.0.9]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [receiver=3.0.9]

I didn't kill the process by my own, I think there isn't any other process that kills this process. Also I run it foreground with nohup. I use nohup because for any reason ssh session terminated, the rsync process doesn't terminate.

What does cause terminating?

Operating system is Debian Wheezy.

8
  • Something killing the rsync process or the ssh session? What if you run in the foreground? Oct 30, 2014 at 19:11
  • Has your swap space been exceeded, if so then the phantom job killer gets activated.
    – mdpc
    Oct 30, 2014 at 19:22
  • @akostadinov I edited my question. Oct 30, 2014 at 19:30
  • @mdpc neither memory nor swap haven't exceeded. Oct 30, 2014 at 19:30
  • 1
    Definitely show us your rsync command, please.
    – chutz
    Oct 22, 2018 at 6:30

1 Answer 1

3

This is an old question, with limited information, but I think what is happening is not an rsync issue (since rsync won't sigkill itself).

I ran into a similar problem which turned out to be a memory issue. The out of memory management in the kernel determines which process to kill by looking at the amount of virtual memory used divided by total time running.

Rsync can consume lots of memory depending on the size and number of files being transferred, and it will have a low run time value. This increases it's score when the kernel calls select_bad_process().

Check memory usage with a simple script after starting rsync that logs rsync memory usage:

while [ 1 ]; do
  pidstat -r -G rsync >> stat.log
  free >> stat.log
done

Also check dmesg around the time rsync dies, if there are OOM errors you'll see them.

You must log in to answer this question.

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