On Fri, 22 Feb 2002, Dave Dykstra wrote:
> > > At the same time, the server child process is doing a 262K read from another
> > > file over the same NFS connection and it takes the same 9 minutes and
> > > eventually suceeds. It only dies because the other server process had died
> > > and it ge
On Fri, Feb 22, 2002 at 12:10:52PM -0500, David Birnbaum wrote:
> On Fri, 22 Feb 2002, Dave Dykstra wrote:
>
> > [adding the mailing list to the Cc after David sent me trusses and other
> > info about his hang. I have trimmed down the tracing info to the relevant
> > pieces.]
> >
> > On Tue, Feb
On Fri, 22 Feb 2002, Dave Dykstra wrote:
> [adding the mailing list to the Cc after David sent me trusses and other
> info about his hang. I have trimmed down the tracing info to the relevant
> pieces.]
>
> On Tue, Feb 19, 2002 at 11:51:27PM -0500, David Birnbaum wrote:
> > I wasn't able to get
[adding the mailing list to the Cc after David sent me trusses and other
info about his hang. I have trimmed down the tracing info to the relevant
pieces.]
On Tue, Feb 19, 2002 at 11:51:27PM -0500, David Birnbaum wrote:
> I wasn't able to get a netstat this time. However, I should be able to
>
D]'
> Subject: Re: large file error is now SIGUSR1 or SIGINT error
>
>
> The SIGUSR1 or SIGINT is just a secondary message in this
> case that you can
> ignore. The receiver side of rsync splits into two
> processes, and that's
> just the message that the sec
On Tue, 12 Feb 2002, Dave Dykstra wrote:
> > Well, I decided to burn some disk space and did a truss of the whole
> > thing...and caught it in the act. It looks as though the first process
> > gets an EPIPE. If memory serves, EPIPE should only occur when the child
> > has died on the other side
> Available via SameTime Connect within Philips, n9hmg on AIM
> > > perl -e 'print pack(,
> > > 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
> > > ".\n" '
> > > "There are some who c
The SIGUSR1 or SIGINT is just a secondary message in this case that you can
ignore. The receiver side of rsync splits into two processes, and that's
just the message that the second one prints after the first one kills it
off because it had a problem. The real problem is your write failure.
I d
I just ran this again and got this error:
leelab/NCBI_Data_old/GenBank/htg
write failed on leelab/NCBI_Data_old/GenBank/htg : Error 0
rsync error: error in file IO (code 11) at receiver.c(243)
Received signal 16. (no core)
rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
The co
On Mon, Feb 11, 2002 at 08:15:46PM -0500, David Birnbaum wrote:
> Dave, et. al,
>
> Well, I decided to burn some disk space and did a truss of the whole
> thing...and caught it in the act. It looks as though the first process
> gets an EPIPE. If memory serves, EPIPE should only occur when the c
o: David Birnbaum <[EMAIL PROTECTED]>
cc: Tim Conway/LMT/SC/PHILIPS@AMEC
Eric Whiting <[EMAIL PROTECTED]>
[EMAIL PROTECTED]
Subject:Re: SIGUSR1 or SIGINT error
Classification:
The fix that went into 2.5.0 was for timeouts that were happening e
ng to 60
seconds is still happening, or if that was only something earlier. Of
course, it's also entirely possible that the "SIGUSR1 or SIGINT error"
message is being caused by a different problem.
- Dave Dykstra
On Thu, Feb 07, 2002 at 10:22:23AM -0500, David Birnbaum wrote:
t;.\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/
. 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: SIGU
On Wed, Feb 06, 2002 at 04:29:49PM -0700, Eric Whiting wrote:
> Dave,
>
> I tried the snapshot... I get an error (after a ./configure;make).
>
> gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -c main.c -o main.o
> main.c: In function `do_cmd':
> main.c:184: `RSYNC_RSH' undeclared (first use in this
nn,
> > > 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
> > > ".\n" '
> > > "There are some who call me Tim?"
> > >
> > >
> > >
> > >
> > > Dave Dykstra <[EMAIL PROTECT
,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
> >
> >
>
680,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 <[
1,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)
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
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[9
On Mon, Feb 04, 2002 at 12:24:02PM -0500, David Birnbaum wrote:
> Howdy,
>
> We occassionally get the following error when running our nightly
> backups:
>
> rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
>
> This happens more on one or two machines than on any of the other
Howdy,
We occassionally get the following error when running our nightly
backups:
rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
This happens more on one or two machines than on any of the others. We've
looked high and low to see if we're mistakenly sending these signals,
23 matches
Mail list logo
