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 run
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-tests
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 _/ _/_/_/
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 14576]
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 be
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 feel
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 behaviour
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
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-files
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
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 solve
14 matches
Mail list logo
