group change causing failure

[Joe Eiler]

OK, I did some more poking around and it is actually the read command that
is failing(well, returning EOF)

I put a couple print statements in and everything is identical until the
failure.  Can anyone give me a hint of how to go about debugging this
further?

Snip from Failing case (group as nobody)

(Client) Protocol versions: remote=28, negotiated=28
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[4]
receiving file list ...
flist.c:1284   f[3]
io.c:775   f[3]
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[4]
io.c:502   fd[3] len[24]
io.c:504   fd[3] ret[0] n[24]
io.c:502   fd[5] len[4]
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[4]
io.c:502   fd[3] len[29]
io.c:504   fd[3] ret[0] n[29]
io.c:504   fd[5] ret[0] n[4]
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[0]
_exit_cleanup(code=12, file=io.c, line=359): entered
_exit_cleanup(code=12, file=io.c, line=359): about to call exit(12)

Snip from good case (group as root)
(Client) Protocol versions: remote=28, negotiated=28
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[4]
receiving file list ...
flist.c:1284   f[3]
io.c:775   f[3]
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[4]
io.c:502   fd[3] len[24]
io.c:504   fd[3] ret[0] n[24]
io.c:502   fd[5] len[4]
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[4]
io.c:502   fd[3] len[29]
io.c:504   fd[3] ret[0] n[29]
io.c:504   fd[5] ret[0] n[4]
io.c:502   fd[3] len[4]
io.c:504   fd[3] ret[0] n[4]
io.c:502   fd[3] len[56]
io.c:504   fd[3] ret[0] n[56]
io.c:777   f[3] c[^Y]
io.c:775   f[3]
io.c:777   f[3] c[^E]
recv_file_name(test1)

Joe
-----Original Message-----
From: Wayne Davison [mailto:wayned at samba.org]
Sent: Tuesday, October 05, 2004 12:37 AM
To: Joe Eiler
Cc: 'rsync at lists.samba.org'
Subject: Re: group change causing failure


On Mon, Oct 04, 2004 at 09:06:01PM -0500, Joe Eiler wrote:
> I just compiled 2.6.3 and am trying to get it to run on linux 2.6.8.1
> kernel with a more or less fedora core2 environment.

I've tested 2.6.3 under a debian sarge setup using a linux 2.6.8.1
kernel.  The only changes I made in your test case were to use inetd
instead of xinetd, and to use "nogroup" instead of "nobody" for the
group (which is a known difference between debian and fedora).  I
couldn't get rsync to fail.

So, you should first check for messages from rsyncd in your syslog to
see if rsync is exiting with an error or dying.  You migh also try
running the rsync daemon without using xinetd (just run rsync --daemon
on its own with the xinetd setup turned off).  If rsync is crashing, you
should enable core dumps (either "rsync --daemon" from a shell where you
have typed "ulimit -c unlimted", or put that command into a script that
runs "rsync --daemon" and run that script from xinetd).

..wayne..