The initial run with an empty destination directory works as expected. When running again rsync halts after "delete_in_dir(.......)" (directory tree omitted) rsync is run locally from command line as root: rsync -avvvn --del --ignore-errors /var/storage /var/backupdir initially run with --delete, and -a with same effect. The last few lines, including exit message when issuing ctrl+c: [sender] make_file(storage/...,*,2) [sender] make_file(storage/...,*,2) [sender] make_file(storage/...,*,2) send_files(77972, /var/storage/...) delete_in_dir(storage/...) rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(506) [sender=3.0.0] _exit_cleanup(code=20, file=rsync.c, line=506): about to call exit(20) Full directory tree omitted. Using Debian Etch.
I'll need more information to help you debug the situation. One first step: be sure you're running a non-stripped version of the rsync executable (so that it has debug symbols) and when it hangs, attach gdb to the middle process of the 3 (for a local copy) or the first of 2 (on the receiving side of a remote copy). Then, ensure it is the generator and output a backtrace: gdb rsync 12345 p am_generator bt p *first_flist p *cur_flist I may be able to figure out the hang by knowing where it happened, but may need more info than that. If you would be willing to generate a core-dump of the generator process, that would allow me to diagnose the hang more fully. E.g. run "ulimit -c unlimited" before starting rsync, and then from inside the right attached process (via gdb) execute the "signal 11" command to make it dump core (or run "kill 11 12345" from the command-line). Then, gzip the core file and send it to me as an attachment in a private email.
Hi Wayne, the bug appears to happen after it has induced a few kernel oops. Rebooting returns expected behaviour. The kernel oops-messages have been given on a number of occasions, with reboots inbetween. It appears to be a consequence of the rather large rsync-sessions I've run (500GB). > I may be able to figure out the hang by knowing where it happened, but may need > more info than that. I'm not quite sure I can provide much more information right now, so I have closed the bug. I'll return if I get the information you need. Might serve as a reference if somebody else encounters it as well, though.