> Maybe. You must be using at least 2.6.4 on both ends of the connection > and not overriding the protocol version below 29. (You can see what > protocol was negotiated by specifying at least four -v options.) If the > remote system has multiple versions of rsync installed, perhaps it is > running an older one unbeknownst to you.
I double checked, and it's definately 2.6.5pre1 on both sides. You can also see this is the provided log file (below). > > Even with keep-alive, if you run something that takes up too much time, > rsync could conceivably still timeout. For instance, using --checksum > with really large files might not get to the keep-alive check often > enough to make a difference. Or using --fuzzy with a lot of missing > files into a large directory could be pretty slow too. (You don't > mention what options you're using, so I'm going to stop guessing at > what might be slowing things down.) > I'm not using any flags like that, only -vvvv on the sender side (previously I was using only -a, but removed it for the test for simplicity). The receiver side isn't the fastest machine in the world, it's a Celeron 566, but there's also nothing really running on it but rsync. > In any case, it would be good to know at what point in the transfer it > was timing out. You might try setting larger levels of verbosity, and > if it still times out, let me know at what was going on at the time of > the failure (perhaps attach strace to the generator process too -- it's > the first (which usually means lowest) PID of the two processes on the > receiving side). > Here's my output from rsync on the sender side (with most of the chunk[n] stuff trimmed out for brevity). I kept an strace log of the receiver side like you asked, and of the sender side for completeness. They're both fairly large (137k and 1.7megs), so I put them on my webserver. They should be available at: http://www.vellmont.com/~steve/rsync-strace-receiver.log http://www.vellmont.com/~steve/rsync-strace-sender.log The full output from rsync is also available if you need it for some reason at: http://www.vellmont.com/~steve/rsync-sender.log opening tcp connection to 192.168.0.4 port 873 opening connection using --server -vvvv . turing (Client) Protocol versions: remote=29, negotiated=29 [sender] make_file(counter-strike source shared.gcf,*,2) [sender] i=0 /home/steve counter-strike source shared.gcf mode=0100700 len=1063117944 flags=0 send_file_list done file list sent send_files starting send_files(0, /home/steve/counter-strike source shared.gcf) count=32611 n=32600 rem=31946 chunk[0] len=32600 offset=0 sum1=77cf1b2f chunk[1] len=32600 offset=32600 sum1=03fb25a9 chunk[2] len=32600 offset=65200 sum1=bf2738ce chunk[3] len=32600 offset=97800 sum1=5cff6268 chunk[4] len=32600 offset=130400 sum1=94090fa6 . . . . chunk[32609] len=32600 offset=1063053400 sum1=a777a26e chunk[32610] len=31946 offset=1063086000 sum1=ec25d882 send_files mapped /home/steve/counter-strike source shared.gcf of size 1063117944 rsync: writefd_unbuffered failed to write 2 bytes: phase "unknown" [sender]: Broken pipe (32) rsync: connection unexpectedly closed (125 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(420) rsync: connection unexpectedly closed (228303 bytes received so far) [sender] _exit_cleanup(code=12, file=io.c, line=420): entered rsync error: error in rsync protocol data stream (code 12) at io.c(420) _exit_cleanup(code=12, file=io.c, line=420): about to call exit(12) > One potential "fix" you could try is to change the initialization of > the "lull_mod" value in generator.c to 1. That would make it call > maybe_send_keepalive() after every file. > > ..wayne.. I'm assuming that wouldn't help this bug, since my test is only sending one file. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html