Harala, Sauli
2001-Sep-13 18:27 UTC
?: 'rsync' hang with 'sshd2' (F-Secure), Digital Unix (OSF1) and HP/UX 11
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@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
Maybe Matching Threads
- "PAM rejected by account configuration" and "fatal: monitor_read: unsupported request: 24" problem at secong sshd instance
- Authentication Problem on Sun Solaris 8 and SSHd2
- openssh-9.9p1 problem with faillock pam module
- augeas syntax for adding similar lines to hosts.allow
- bzip2 directory won't build on OSF1 due to C99 code and -std1 option (PR#7257)