?: 'rsync' hang with 'sshd2' (F-Secure), Digital Unix (OSF1) and
HP/UX 11
Harala, Sauli
sauli.harala at eds.com
Thu Sep 13 18:27:29 EST 2001
Hi,
I have managed to test this same transfer reliably with the
Linux boxes and open-ssh, but I am in trouble with the
OSF1 4.0 (Digital Unix) being the server sending files from a single
directory to the HP/UX 11 - being the client
The 'sshd2' (and ssh2) in both ends is installed as root (and starts
probably from 'rc')
The 'rsync' (2.4.6) in both end is just installed as a single binary
in the stadard user local directory - no '--daemon' mode has been tested
yet.
The 'OSF/1 server side already has the
http://www.clari.net/~wayne/rsync-nohang.patch
included - the client side is still missing it
Tthe patch included in the OSF side
did not have any affect on the trouble.
The terminal 'ssh' connection between the machines
works OK. The 'scp' works also (though a bit slowly ...)
I have tried many combinations of swithces, but e.g.the normal single
directory sync:
./rsync -e /usr/local/bin/ssh --rsync-path=/usr/users/rem_usr/bin/rsync
rem_usr at rem_host:/usr/users/rem_usr/cpy_src/ ./cpy_target/
executed on HP/UX 11 side seems to be hanging.
It seems that the 'rsync' transfer will start but it may hang
without any proper error messages on the client side.
It may e.g. transfer 0 to 80 of several ~4MB
files - (most often count is 0)
- and when it hangs it looks like the forked
'sshd' daemon (owned by root) on the OSF/1 server
side would stop processing after short boost
- though it remains alive as well the
'rsync' daemon running (well... sleeping)
under standard end-user ID.
When the '--verbose' is used on the client side,
the result tells that it is receiving the
directory list, and it lists
the files it has transferred (most often none
appears)
A partially transferred file may remain in the
receiving directory with the temporary name.
The client running on HP/UX 11 does
not receive any error information -
so it will hang waiting for ever
(I have not tested the --timeout yet)
Only way to restart is to
close the client side with '^C' and restart.
Reading the mail archive, it seems
that the 'ssh' transport has caused much trouble
with some other 'rsync' users.
I can configure & establish a verbose
version of sshd2 proccess at the OSF1/side
with a private port(=1888) and standard user ID - and
I am capable to connect through it with the normal 'ssh'
client from the HP/UX side - but I have not
yet been able to configure the remotely starting 'rsync' to use this
'private running' sshd daemon - How this would be possible ?
Quite a long story, but if you know some suggestions,
please let me know. (I am not experience
debugging neither the 'ssh' nor 'rsync' traffic.)
I have not used any special options to compile the 'rsync' - the
'off-the-net'
source package was compiling fine with OSF/1 after configure - the
HP/UX version produced some more trouble when compiled with aCC...
I have also tried to read the mailing-list archives,
but so far none of the hints found have hit the point.
Regards,
sh
----
Sauli Harala
EDS Finland Oy
More information about the rsync
mailing list