Currently 2.5.1pre3. I haven't tested that problem lately, though. I'll
get the newest up and try a full sync. It's worth a try. I'll feel
really stupid, though, if i've put all this work into newsync (perl
driving find|diff|tar|lzop) and it's fixed in rsync. I think our case
will always create problems, though, with the broken nfs unlink in the
nfs3 interface on the NAS, and the broken nfs2 client on the solaris
machines (mtime bug). I won't let this influence my test, though ;-).
Tim Conway
[EMAIL PROTECTED]
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
Dave Dykstra <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/06/2002 03:41 PM
To: Eric Whiting <[EMAIL PROTECTED]>
cc: Tim Conway/LMT/SC/PHILIPS@AMEC
David Birnbaum <[EMAIL PROTECTED]>
[EMAIL PROTECTED]
Subject: Re: SIGUSR1 or SIGINT error
Classification:
Looks like a fix for that went into 2.5.0. See revision 1.87 at
http://cvs.samba.org/cgi-bin/cvsweb/rsync/io.c
Tim & David, what version are you running?
2.5.2 has some serious problems, Eric. Try the latest development
snapshot at
rsync://rsync.samba.org/ftp/unpacked/rsync/
or
ftp://rsync.samba.org/pub/unpacked/rsync/
- Dave Dykstra
On Wed, Feb 06, 2002 at 11:33:43AM -0700, Eric Whiting wrote:
> Make that 2 of us who need to specify a large timeout.
>
> I have found that I have to set the timeout to a large value (10000) to
> get the rsyncs to run successfully. Leaving it at the default seemed to
> cause timeout/hang problems. Of course I still running a 2.4.6dev
> version. I had troubles with 2.5.[01]. (solaris/linux mix of of rsync
> clients/servers)
>
> I need to try 2.5.2 as soon as I get a chance. Looks like some good
> fixes are happening in 2.5.2.
>
> eric
>
>
>
> On Wed, 2002-02-06 at 10:39, [EMAIL PROTECTED] wrote:
> > When i was getting these, I traced the process and its children
(solaris:
> > truss -f). I found that one of the spawned threads was experiencing
an io
> > timeout while the filelist was building. I had set no timeout, but it
did
> > it at 60 seconds every time. I found that this corresponded to a
> > SELECT_TIMEOUT parameter, which was set to 60 if IO_TIMEOUT was 0. BY
> > setting my timeout to 86400 (1 day), i stopped those. Of course,
then, it
> > choked farther along, but that's another story.
> > Try setting a timeout, even if you don't want one. Make it the
longest
> > the process should ever take.
> >
> > Tim Conway
> > [EMAIL PROTECTED]
> > 303.682.4917
> > Philips Semiconductor - Longmont TC
> > 1880 Industrial Circle, Suite D
> > Longmont, CO 80501
> > Available via SameTime Connect within Philips, n9hmg on AIM
> > perl -e 'print pack(nnnnnnnnnnnn,
> >
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
> > ".\n" '
> > "There are some who call me.... Tim?"
> >
> >
> >
> >
> > Dave Dykstra <[EMAIL PROTECTED]>
> > Sent by: [EMAIL PROTECTED]
> > 02/06/2002 10:16 AM
> >
> >
> > To: David Birnbaum <[EMAIL PROTECTED]>
> > cc: [EMAIL PROTECTED]
> > (bcc: Tim Conway/LMT/SC/PHILIPS)
> > Subject: Re: SIGUSR1 or SIGINT error
> > Classification:
> >
> >
> >
> > On Tue, Feb 05, 2002 at 11:28:54AM -0500, David Birnbaum wrote:
> > > I suspected that might be the case...now...how to determine the
"real"
> > > problem? Does rsync log it somewhere? lsof shows that
STDERR/STDOUT
> > are
> > > going to /dev/null, so I hope it's not writing it there. Nothing
> > > informative in syslog, just the message about the SIG:
> > >
> > > Feb 5 09:49:41 hite rsyncd[9279]: [ID 702911 daemon.warning]
rsync
> > error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
> > >
> > > Any clues?
> >
> >
> > I'm sorry, but I don't have any more suggestions.
> >
> > - Dave Dykstra
> >
> >
> >
> >
> >
>
