Re: rsync stops/hangs (from windows to debian)

2007-10-08 Thread Miles Raymond

Awesome suggestion, but unfortunately it doesn't work in my case. =(

I have noticed, however, that rsync does work from some of the windows servers 
to the Debian servers.  So even though our main file store can't send files 
directly to our Debian servers, I've set up one of the windows servers to then 
rsync the data over to the Debian servers.  For now, that should hold out until 
I can get all our servers replaced with Debian.

-Miles

Matt McCutchen wrote:

As a workaround, you might try setting a --bwlimit, as Wayne suggested here:

https://bugzilla.samba.org/show_bug.cgi?id=2208#c9

If a low --bwlimit setting doesn't fix the problem, I would be curious
if a tweak to the way --bwlimit is implemented (e.g., moving the
sleep_for_bwlimit call *before* the write in writefd_unbuffered, or
perhaps lowering bwlimit_writemax) would help.  Please tell me if you
are interested in experimenting with this.

Matt

--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


Re: rsync stops/hangs (from windows to debian)

2007-10-05 Thread Miles Raymond

I'm not using rsync through ssh since this is on an internal network.  Would 
pipes still be used?

The only difference I can tell between my situation and Alain's is that my case 
the windows client is sending files instead of receiving.

Are there any suggestions for a work-around other than switch all the computers 
to *nix (which I'm in the process of doing anyway)?  I'm hoping for a more 
immediate solution...

-Miles Raymond

Matt McCutchen wrote:

On 10/4/07, Wayne Davison [EMAIL PROTECTED] wrote:

Yes, due to a bug in cygwin's pipe code (the pipe that carries data
between rsync and ssh).  Until cygwin fixes its pipe code, you can only
reliably rsync data to/from a cygwin system if you avoid pipes (e.g. use
a daemon transfer).


I'm not sure the problem is limited to pipes.  Alain Deseine reported
a hang when a Cygwin client accessed a daemon:

http://lists.samba.org/archive/rsync/2007-August/018393.html

Matt

--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


Re: rsync stops/hangs (from windows to debian)

2007-10-05 Thread Fabian Cenedese
At 01:26 05.10.2007 -0700, Miles Raymond wrote:
I'm not using rsync through ssh since this is on an internal network.  Would 
pipes still be used?

The only difference I can tell between my situation and Alain's is that my 
case the windows client is sending files instead of receiving.

Are there any suggestions for a work-around other than switch all the 
computers to *nix (which I'm in the process of doing anyway)?  I'm hoping for 
a more immediate solution...

You can try to build (or find) a cygwin version of the new 3.0.0 or the
cvs version. I also had stalls using the Linux 2.6.9 that were solved
using the newer rsync (so no cygwin involved). I don't know if a simple
bugfix was responsible for this or the new protocol 30. In the latter case
you need to have the new rsync on both ends or they use an earlier
protocol.

bye  Fabi


-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


rsync stops/hangs (from windows to debian)

2007-10-04 Thread Miles Raymond

We've been using rsync to send updates to our webservers from a central 
location for years.  All the webservers used to be Windows 2000 Server running 
rsync 2.6.3.  Recently I've been trying to replace them with Debian servers 
with rsync 2.6.9.  The central file server is a Windows 2000 Server using the 
cwRsync binary.  It was also 2.6.3 until I upgraded it to use 2.6.9 also.

The initial rsync (2.6.3 on Windows) to the Debian server (2.6.9) went without 
any hiccup.  However, any other rsync always hangs on a small file shortly 
after starting.  I tried upgrading rsync to 2.6.9 on the sending side.  I tried 
using older protocol versions (28,27).  Then I read the website and searched 
google for possible information.  From what I read from google, this seems to 
be a common problem with rsync on windows.  The rsync website suggests to run 
rsync with strace on the receiving side, but doesn't suggest what to do with 
the data once obtaining it.

Here is the last portion of the dump file given by 'strace -f /usr/bin/rsync 
--no-detach --daemon --config /etc/rsyncd.conf' where it stops transferring.  
The problem is that it doesn't give any error, not even a connection error, but 
just stops transferring any data.

Does anyone have any solutions for this or suggestions to try?

-Miles Raymond

*** DUMP ***

[pid  3023] close(5)= 0
[pid  3023] close(7)= 0
[pid  3023] lstat64(images.paybycheck.com/.phonehead.gif.7ERoOb, 
{st_mode=S_IFREG|0700, st_size=11082, ...}) = 0
[pid  3023] chmod(images.paybycheck.com/.phonehead.gif.7ERoOb, 0755) = 0
[pid  3023] rename(images.paybycheck.com/.phonehead.gif.7ERoOb, 
images.paybycheck.com/phonehead.gif) = 0
[pid  3023] open(images.paybycheck.com/phoneheadd.gif, O_RDONLY|O_LARGEFILE) 
= 5
[pid  3023] fstat64(5, {st_mode=S_IFREG|0755, st_size=25934, ...}) = 0
[pid  3023] open(images.paybycheck.com/.phoneheadd.gif.yPBy3q, 
O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 7
[pid  3023] fchmod(7, 0700) = 0
[pid  3023] read(5, 
GIF89a\212\2s\0\367\377\0\377\377\377\336\336\336\347\347..., 16800) = 16800
[pid  3023] read(5, 
\321/\346\320\33\375\10\214\300\5\260:\5p\0\2,\355\327..., 9134) = 9134
[pid  3023] write(7, 
GIF89a\212\2s\0\367\377\0\377\377\377\336\336\336\347\347..., 25934) = 25934
[pid  3023] close(5)= 0
[pid  3023] close(7)= 0
[pid  3023] lstat64(images.paybycheck.com/.phoneheadd.gif.yPBy3q, 
{st_mode=S_IFREG|0700, st_size=25934, ...}) = 0
[pid  3023] chmod(images.paybycheck.com/.phoneheadd.gif.yPBy3q, 0755) = 0
[pid  3023] rename(images.paybycheck.com/.phoneheadd.gif.yPBy3q, 
images.paybycheck.com/phoneheadd.gif) = 0
[pid  3023] open(images.paybycheck.com/phoneheaders/accident.jpg, 
O_RDONLY|O_LARGEFILE) = 5
[pid  3023] fstat64(5, {st_mode=S_IFREG|0755, st_size=66799, ...}) = 0
[pid  3023] getxattr(images.paybycheck.com/phoneheaders, 
system.posix_acl_default, 0xbfa081c0, 132) = -1 EOPNOTSUPP (Operation not supported)
[pid  3023] open(images.paybycheck.com/phoneheaders/.accident.jpg.xJkXiG, 
O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 7
[pid  3023] fchmod(7, 0700) = 0
[pid  3023] read(5, 
\377\330\377\340\0\20JFIF\0\1\2\1\0H\0H\0\0\377\355\10..., 16800) = 16800
[pid  3023] select(4, [3], [], NULL, {60, 0}) = 1 (in [3], left {60, 0})
[pid  3023] read(3, 
\363\377\377\377\362\377\377\377\361\377\377\377\360\377..., 8184) = 56
[pid  3023] read(5, 
\2078\255\221\263l2\321\330\22j#\231+\256\217e\206a\36..., 16800) = 16800
[pid  3023] select(4, [3], [], NULL, {60, 0}) = 1 (in [3], left {59, 984000})
[pid  3023] read(3, 
\345\377\377\377\344\377\377\377\343\377\377\377\342\377..., 8184) = 300
[pid  3023] read(5, 
\206\303oE\267\364\311/\254\254o\234\304\327k\4\21(\344..., 16800) = 16800
[pid  3023] read(5, 
i\f\274:\3628+K\362\f\227\350\355\243G\24\257}\343\256..., 16399) = 16399
[pid  3023] write(7, 
\377\330\377\340\0\20JFIF\0\1\2\1\0H\0H\0\0\377\355\10..., 66799) = 66799
[pid  3023] close(5)= 0
[pid  3023] close(7)= 0
[pid  3023] lstat64(images.paybycheck.com/phoneheaders/.accident.jpg.xJkXiG, 
{st_mode=S_IFREG|0700, st_size=66799, ...}) = 0
[pid  3023] chmod(images.paybycheck.com/phoneheaders/.accident.jpg.xJkXiG, 
0755) = 0
[pid  3023] rename(images.paybycheck.com/phoneheaders/.accident.jpg.xJkXiG, 
images.paybycheck.com/phoneheaders/accident.jpg) = 0
[pid  3023] select(4, [3], [], NULL, {60, 0} unfinished ...
[pid  3009] ... select resumed )  = 0 (Timeout)
[pid  3009] select(4, NULL, [3], [3], {60, 0} unfinished ...
[pid  2985] ... select resumed )  = 0 (Timeout)
[pid  2985] select(4, NULL, [3], [3], {60, 0} unfinished ...
[pid  3011] ... select resumed )  = 0 (Timeout)
[pid  3011] select(4, NULL, [3], [3], {60, 0} unfinished ...
[pid  3006] ... select resumed )  = 0 (Timeout)
[pid  3006] select(4, NULL, [3], [3], {60, 0} unfinished ...
[pid  3022] ... select resumed )  = 0 

Re: rsync stops/hangs (from windows to debian)

2007-10-04 Thread Wayne Davison
On Thu, Oct 04, 2007 at 10:24:23AM -0700, Miles Raymond wrote:
 From what I read from google, this seems to be a common problem with
 rsync on windows.

Yes, due to a bug in cygwin's pipe code (the pipe that carries data
between rsync and ssh).  Until cygwin fixes its pipe code, you can only
reliably rsync data to/from a cygwin system if you avoid pipes (e.g. use
a daemon transfer).

..wayne..
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


Re: rsync stops/hangs (from windows to debian)

2007-10-04 Thread Matt McCutchen
On 10/4/07, Wayne Davison [EMAIL PROTECTED] wrote:
 Yes, due to a bug in cygwin's pipe code (the pipe that carries data
 between rsync and ssh).  Until cygwin fixes its pipe code, you can only
 reliably rsync data to/from a cygwin system if you avoid pipes (e.g. use
 a daemon transfer).

I'm not sure the problem is limited to pipes.  Alain Deseine reported
a hang when a Cygwin client accessed a daemon:

http://lists.samba.org/archive/rsync/2007-August/018393.html

Matt
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html