The Samba-Bugzilla – Bug 1495
2.6.x generates protocol stream error running as server daemon on HP-UX 11.11
Last modified: 2005-03-16 16:48:11 UTC
On HP-UX 11.11, running rsync as an inet daemon, when attempting to contact from
a client workstation or from the local server, the following behavior is seen:
$ /usr/local/bin/rsync262 -an gordie::
$ /usr/local/bin/rsync262 -an gordie::tns /tmp
rsync: connection unexpectedly closed (24 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)
The same error occurs when using 2.6.0 and 2.6.2 as the server; it appears to be
independent of the client rsync revision (we've used both 2.6.2 and 2.4.6; when
the older revision is used to make the connection, the error simply reads
"unexpected EOF in read_timeout"). The error does *not* appear when running the
server at either revision 2.4.6 or 2.5.6.
Most revisions were compiled on HP-UX 11.11 using HP's ANSI C compiler; a TWW
(The Written Word) version also tested was compiled using gcc (not sure which
revision), and delivered as part of their 6.1 toolset revision.
$ /usr/local/bin/rsync --version
rsync version 2.4.6 protocol version 24
Written by Andrew Tridgell and Paul Mackerras
$ /usr/local/bin/rsync262 --version
rsync version 2.6.2 protocol version 28
Copyright (C) 1996-2004 by Andrew Tridgell and others
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
no IPv6, 32-bit system inums, 64-bit internal inums
I don't see this failure, so you'll have to help figure out why the remote
daemon is going away. First, look in the log file to see if rsync died with an
error. It is possible, for instance, that the fixed "refuse options" setting in
the config file is refusing to allow the transfer to happen (if it was
configured to do so).
Did you find any log messages that indicated why this is failing?
If you don't see a log message, you can try halting the rsync daemon and running
it will strace, like this:
strace -f rsync --daemon --no-detach 2>/tmp/strace.out
(Ctrl-C that after you run the failing test and restart it normally.)
That will let you look at the system calls that happened right before the failure.
Closing due to lack of response from bug reporter.