Bug 5343 - rsync does nothing after first time
rsync does nothing after first time
Status: CLOSED WORKSFORME
Product: rsync
Classification: Unclassified
Component: core
3.0.0
IA64 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-20 15:52 UTC by rolmol
Modified: 2008-07-26 10:40 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rolmol 2008-03-20 15:52:07 UTC
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.
Comment 1 Wayne Davison 2008-03-21 12:26:05 UTC
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.
Comment 2 rolmol 2008-03-21 15:53:33 UTC
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.