Re: probbable generator hang bug in rsync

Here's the strace output: I'm not terribly familiar with system
programming, so I'm unsure how to interpret it.

write(4, "2005/10/03 13:58:12 [16992] recv"..., 137) = 137
select(8, [7], [3], NULL, {60, 0}) = 1 (in [7], left {59, 660000})
select(8, [7], [], NULL, {60, 0}) = 1 (in [7], left {60, 0})
read(7, "m\0\0\n", 4) = 4
select(8, [7], [], NULL, {60, 0}) = 1 (in [7], left {60, 0})
read(7, "recv localhost.localdomain [127."..., 109) = 109
getpid() = 16992
time(NULL) = 1128365892
write(4, "2005/10/03 13:58:12 [16992] recv"..., 137) = 137
select(8, [7], [3], NULL, {60, 0}) = 1 (in [7], left {58, 460000})
select(8, [7], [], NULL, {60, 0}) = 1 (in [7], left {60, 0})
read(7, "2\0\0\10", 4) = 4
select(8, [7], [], NULL, {60, 0}) = 1 (in [7], left {60, 0})
read(7, "rsync: read error: Connection re"..., 50) = 50
getpid() = 16992
time(NULL) = 1128365894
write(4, "2005/10/03 13:58:14 [16992] rsyn"..., 78) = 78
select(4, NULL, [3], NULL, {60, 0}) = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, NULL, WNOHANG, NULL) = 17007
wait4(-1, NULL, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {0x401ddb30, [CHLD], SA_RESTORER|SA_RESTART, 0x400c1978}, {0x401ddb30, [CHLD], SA_RESTORER|SA_RESTART, 0x400c1978}, 8) = 0
sigreturn() = ? (mask now [RTMIN])
select(4, NULL, [3], NULL, {60, 0}) = 0 (Timeout)
select(4, NULL, [3], NULL, {60, 0}) = 0 (Timeout)


On Sat, Sep 24, 2005 at 12:18:35AM -0700, Wayne Davison wrote:
> On Wed, Sep 21, 2005 at 10:25:41PM -0500, Steve Sether wrote:
> > I have about 10 modules configured and I still get this problem.
> > Any advice on finding out what's going on Wayne?
>
> I'd suggest that you get a system-call trace of the generator that
> covers the period of activity during the socket closing. We need to see
> if the generator gets any kind of a notification that the socket is now
> closed. What should happen is that the select() call should return that
> the socket's fd is now ready for a write() call, and that write() call
> should return an EOF error. If the select() doesn't ever wake up, that
> would seem to indicate that the socket going to rsync is really still
> open (perhaps because stunnel didn't close the local socket yet). Or,
> if the select() call did wake up, perhaps the write() call returned a
> try-again error (such as EAGAIN) instead of an EOF error. If so, that
> might indicate an OS bug.
>
> ..wayne..
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html