Bug 1495 - 2.6.x generates protocol stream error running as server daemon on HP-UX 11.11
Summary: 2.6.x generates protocol stream error running as server daemon on HP-UX 11.11
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 2.6.2
Hardware: PA-RISC HP-UX
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2004-06-30 12:12 UTC by Hugh Williams
Modified: 2005-03-16 16:48 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Hugh Williams 2004-06-30 12:12:37 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
Comment 1 Wayne Davison 2004-06-30 13:44:34 UTC
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).
Comment 2 Wayne Davison 2004-07-16 13:21:51 UTC
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.
Comment 3 Wayne Davison 2004-09-20 23:40:40 UTC
Closing due to lack of response from bug reporter.