rsync 2.5.6 still hangs

[John Van Essen]

On Tue, 23 Sep 2003, jw schultz <jw at pegasys.ws> wrote:
> On Tue, Sep 23, 2003 at 11:18:13AM +0200, Martin Schröder wrote:
>> Hi,
>> we have two Linux systems (2.4.21 and 2.2.19) with rsync 2.5.6
>> The 2.4.21 system does backups via cron by rsync to the 2.2.19
>> system.

Are you sure that you are using 2.5.6 on both machines?  Versions
prior to 2.5.6 did not reset the timer during the file transfer
phase (as I recall) and so the timeout would expire too soon,
before all the files have been sent.  My guess is that the 2.2.19
system has an older version of rsync.
 
>> Via cron rsync always exits with (it is called with --timeout=60)
>> ----------
>> rsync error: timeout in data send/receive (code 30) at io.c(103)
>> ----------
>> 
>> Or with -vvvv
>> ----------
>> make_file(6,tex/alt/12.3/share/texmf/tex/latex/base/omxcmex.fd)
>> io timeout after 60 seconds - exiting
>> _exit_cleanup(code=30, file=io.c, line=103): entered
>> rsync error: timeout in data send/receive (code 30) at io.c(103)
>> _exit_cleanup(code=30, file=io.c, line=103): about to call exit(30)
>> ----------
>> 
>> The file varies.

Also keep in mind that the timeout applies to the delay while the receiver
is building its filelist after the sender has sent its filelist to the
receiver.  If more than {--timeout} seconds (60 in your case) elapse
before the receiver starts requesting files from the sender, the sender
will close the connection.

This apparently doesn't apply (yet) in your case but it's something to
consider when choosing a timeout value.  60 is very short.

>> Interestingly this does not happen when rsync is called
>> interactively. %-{
>> 
>> Any idea how to avoid this?
> 
> When there is a difference in behaviour between interactive
> and cron it will be caused by a difference in the
> environment.  Often PATH, sometimes "LD_*", sometimes
> something else.

It could also be caused by enough blocks being cached in memory to
allow the task to complete more quickly - such would be the case with
repeated interactive testing.

> Also, use of more v than -vv can itself cause problems.

True.
-- 
        John Van Essen  Univ of MN Alumnus  <vanes002 at umn.edu>
        3DGamers  Systems Software Support  <jve at 3dgamers.com>