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.

Barmar
  • 344
  • 1
  • 8
Arash Mousavi
  • 658
  • 3
  • 8
  • 21
  • Something killing the rsync process or the ssh session? What if you run in the foreground? – akostadinov Oct 30 '14 at 19:11
  • Has your swap space been exceeded, if so then the phantom job killer gets activated. – mdpc Oct 30 '14 at 19:22
  • @akostadinov I edited my question. – Arash Mousavi Oct 30 '14 at 19:30
  • @mdpc neither memory nor swap haven't exceeded. – Arash Mousavi Oct 30 '14 at 19:30
  • try if you can reproduce the issue in the foreground (without `nohup`). If your ssh connection is flaky, then `rsync` can die. You don't list your `rsync` full command but most probably it is operating over ssh to a remote host, so if that connection dies for whatever reason, `rsync` would also die. I've seen ssh servers terminating connections ater some byte limit. So first make sure your ssh connections are stable. – akostadinov Oct 30 '14 at 19:59
  • Also, if you are using rsync's -z option, try without it. Sometimes that triggers an error somewhere (unclear as to what exactly). – wurtel Oct 31 '14 at 11:05
  • 1
    Definitely show us your rsync command, please. – chutz Oct 22 '18 at 06:30
  • Related: https://serverfault.com/questions/535885/rsync-unexplained-error-received-sigint-sigterm-or-sighup . It suggests using `-v` or `-vv` to get diagnostic output. – ivan_pozdeev Nov 23 '18 at 09:10

1 Answers1

2

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.

Ed King
  • 931
  • 4
  • 9