> Some feedback. I'd been having trouble with rsync hanging or early EOF
> timeouts.
>...
> versions over many days and believe that both the kernel upgrade and the
> latest rsync cvs were necessary.
nothing hangs in the case below, the job is done, but what produces the
message "Aborted by user
Some feedback. I'd been having trouble with rsync hanging or early EOF
timeouts.
Problem occurred on 2 identical receiving machines.
I upgraded from Linux kernel 2.4.2 (RH 7.1) to 2.4.7 on the receiving
machines. Sender machines are standard Linux RH 6.1 and RH 6.2 kernel..
Receiving machines are
On Thu, Jul 05, 2001 at 10:58:22AM -0700, you [Jos Backus] claimed:
> On Thu, Jul 05, 2001 at 12:48:06PM -0500, Dave Dykstra wrote:
> > If you really want it to stay in the foreground, edit become_daemon in
> > socket.c.
>
> It would be nice to have this available as an option so rsyncd can be ru
Dave Dykstra wrote:
> You shouldn't have to have it be in the foreground in order for strace -f
You're right, I was not aware of that option. And I thought I
knew my way around strace.
Here's what strace shows me:
[pid 14576] open("/tmp/rsyncd.lock", O_RDWR|O_CREAT|0x8000, 0600) = 4
[pid 1457
On Thu, Jul 05, 2001 at 12:48:06PM -0500, Dave Dykstra wrote:
> If you really want it to stay in the foreground, edit become_daemon in
> socket.c.
It would be nice to have this available as an option so rsyncd can be run
under djb's daemontools.
--
Jos Backus _/ _/_/_/S
On Thu, Jul 05, 2001 at 12:38:00AM -0500, Phil Howard wrote:
> Wayne Davison wrote:
>
> > We certainly do need to be careful here, since the interaction between
> > the various read and write functions can be pretty complex. However, I
> > think that the data flow of my move-files patch stress-t
Wayne Davison wrote:
> We certainly do need to be careful here, since the interaction between
> the various read and write functions can be pretty complex. However, I
> think that the data flow of my move-files patch stress-tests this code
> fairly well, so once we've done some more testing I fe
On Wed, 27 Jun 2001, Martin Pool wrote:
> This is getting disturbingly complex. I realize the problem is
> complex too, so this is no slur on Wayne's coding. My gut reaction is
> that if we start adding this then the program's behaviour will become
> even more baroque.
We certainly do need to b
On Tue, 26 Jun 2001, Wayne Davison wrote:
> Since read_int() is a fairly high-level call, I had to manually ensure
> that a flush doesn't happen and to ensure that reading the redo_fd
> doesn't try to read the io_error_fd (both to avoid nested read
> attempts on the redo_fd).
In case you're wonde
On 26 Jun 2001, Wayne Davison <[EMAIL PROTECTED]> wrote:
> Here's a solution with a non-growing buffer.
This is getting disturbingly complex. I realize the problem is
complex too, so this is no slur on Wayne's coding. My gut reaction is
that if we start adding this then the program's behaviou
On Mon, 25 Jun 2001, Andrew Tridgell wrote:
> see if we can find a solution without a buffer.
Here's a solution with a non-growing buffer. This code keeps the
receiver->generator pipe clear by reading the ints and setting redo
flags in a character array (of flist->count elements). I'm avoiding
On Mon, 25 Jun 2001, Andrew Tridgell wrote:
> I've applied your simple nohang patch.
Cool. That's the one that affects the most people.
> Instead we need a way of reproducing the bug and see if we can find a
> solution without a buffer.
You can minimize the buffer usage by applying my move-fil
Wayne,
I've applied your simple nohang patch. The longer nohang patch I'm not
nearly as confident of. It goes back to a method used in early
versions of rsync where it uses a buffer that can grow indefinately.
Just some history on this. The earliest versions of rsync had no
buffer, then when I
On 22 Jun 2001, [EMAIL PROTECTED] wrote:
> I have been testing this patch in a duplicate of our production
> environment, for a week now. With the patch, the runs complete.
> I'm handling 86756263K in 1816688 files (at last count) average 47K
> files (ranging up to about .5G).
> It seems to so
I have been testing this patch in a duplicate of our production environment, for a
week now. With the patch, the runs complete. I'm handling
86756263K in 1816688 files (at last count) average 47K files (ranging up to about
.5G). It seems to solve the problems. I think it constitutes rsync
Thanks for committing the crash-bug fix, Martin.
I'm curious if you have any comments on my fixes for the 2 protocol-hangs
I discovered? The most common problem that people encounter is the bug I
fixed second, which is fixed by a very simple patch:
Index: main.c
--- main.c 29 May 2001 14:3
16 matches
Mail list logo
