Bernhard Wesely
2006-Sep-11 14:32 UTC
error in rsync protocol data stream (code 12) at io.c(463) on HP-UX 11.23
Hello,
We discovered a slight problem with rsync 2.6.8 on HP-UX 11.23 on Itanium2.
When trying to get a directory listing via:
# oracle@DEV1[]:/~ > rsync dev1::deploy
drwxr-xr-x 96 2006/09/06 12:57:36 .
drwxrwxrwx 96 2006/09/11 15:35:33 test
# ...
it works flawlessly, but when trying to get a subdirectory we get the
following error:
# DEV1:/etc# rsync dev1::deploy/test
# rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
# rsync error: error in rsync protocol data stream (code 12) at io.c(463)
# [receiver=2.6.8]
we are using rsync 2.6.8 (as mentioned before)
# oracle@DEV1[]:/~ > rsync --version
# rsync version 2.6.8 protocol version 29
# Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others.
# <http://rsync.samba.org/>
# Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
# inplace, no IPv6, 32-bit system inums, 64-bit internal inums
our rsyncd.conf looks like this:
# log file = /log/rsyncd/test.log
# pid file = /log/rsyncd/test.pid
# use chroot = true
# [deploy]
# comment = Test
# path = /f/deploynew/ap
# gid = appl
# uid = gso
# read only = no
as this error message semms pretty generic and looking for any answers via
the web didn't
turn out that useful after all. So we installed tusc and traced rsync.
a failing request (rsync dev1::deploy/test) looks like this:
---------------------------------------------------------------
[6951] select(4, 0x7fffa0f8, 0x7fffa1f8, NULL, 0x7fffa0f0) ......... = 1
[6951] read(3, "\n", 1) ............................................ =
1
[6951] brk(0x4003e000) ............................................. = 0
[6951] lstat(".", 0x7fff9760) ...................................... =
0
[6951] open("../", O_RDONLY|0x200000, 026540) ...................... =
6
[6951] fstat(6, 0x7fff9840) ........................................ = 0
[6951] fcntl(6, F_SETFD, 0) ........................................ = 0
[6951] sysfs(GETFSIND, 0xc015ac30, 0x777df220) ..................... = 10
[6951] brk(0x40042000) ............................................. = 0
[6951] close(6) .................................................... = 0
[6951] getaccess("/", -34, -5, NULL, NULL, NULL) ................... =
5
[6951] open("/", O_RDONLY|0x200000, 0) ............................. =
6
[6951] fstat(6, 0x7fff8440) ........................................ = 0
[6951] fcntl(6, F_SETFD, 0) ........................................ = 0
[6951] sysfs(GETFSIND, 0xc015ac30, 0x777df220) ..................... = 10
[6951] getdents(6, 0x4003d820, 16384) .............................. = 152
[6951] stat64("/test", 0x7fff84e0) ................................. =
0
[6951] getdents(6, 0x4003d820, 16384) .............................. = 0
[6951] close(6) .................................................... = 0
[6951] Received signal 11, SIGSEGV, in user mode, [SIG_DFL], partial
siginfo
[6951] Siginfo: si_code: SEGV_ACCERR, faulting address: 0, si_errno: 0
[6951] PC: 00000001000000a0.0 break.m 0x16000
[6951] exit(11) [implicit] .........................................
WIFSIGNALED(SIGSEGV)
[6948] Received signal 18, SIGCLD, in select(), [caught], no siginfo
[6948] select(5, 0x7fffe468, NULL, NULL, NULL) ..................... ERR#4
EINTR
[6948] waitpid(-1, NULL, WNOHANG) .................................. = 6951
[6948] waitpid(-1, NULL, WNOHANG) ..................................
ERR#10 ECHILD
[6948] select(5, 0x7fffe468, NULL, NULL, NULL) .....................
[sleeping]
---------------------------------------------------------------
the only interesting thing in my opinion is the line:
[6951] open("../", O_RDONLY|0x200000, 026540)
why get "../" from a chrooted environment? There's nothing there,
as we
have a new "/" .
Any help will be appreciated,
Thanks,
Bernhard
Paul Slootman
2006-Sep-11 14:42 UTC
error in rsync protocol data stream (code 12) at io.c(463) on HP-UX 11.23
On Mon 11 Sep 2006, Bernhard Wesely wrote:> [6951] getdents(6, 0x4003d820, 16384) .............................. = 152 > [6951] stat64("/test", 0x7fff84e0) ................................. = 0 > [6951] getdents(6, 0x4003d820, 16384) .............................. = 0 > [6951] close(6) .................................................... = 0 > [6951] Received signal 11, SIGSEGV, in user mode, [SIG_DFL], partial> --------------------------------------------------------------- > > the only interesting thing in my opinion is the line: > [6951] open("../", O_RDONLY|0x200000, 026540)Well, IMHO the interesting thing is the SIGSEGV, which causes the process to die, which results in the "prococol error". It would be interesting to see where the SIGSEGV occurs; this probably entails getting a core dump and using a debugger to see what goes wrong. Paul Slootman