rsync - Jan 2009 - Rsync crash

Hello,

I'm using an rsync server on a Linux packages repository (deb packages)
to sync all mirrors.
The mirrors sync every 10 minutes. Most of the time, there is nothing to
sync, except a timestamp file, so the sync is pretty fast.

Anyway, after it has been working well for some time (between 2 and
24hours), the rsync daemon crashes. It is still running but seems to
retry something infinitly.

The rsync log doesn't outputs anything before the crash (just the log of
mirrors sync). I 'straced' the rsync process and have the following
outputs :

select(6, [4 5], NULL, NULL, NULL)      = 1 (in [5])
accept(5, {sa_family=AF_INET, sin_port=htons(37870),
sin_addr=inet_addr("xxxxxxxxxxxx")}, [16]) = 3
rt_sigaction(SIGCHLD, {0x80768c0, [], SA_NOCLDSTOP}, NULL, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7e196f8) = 7117
close(3)                                = 0
select(6, [4 5], NULL, NULL, NULL)      = 1 (in [4])
accept(4, {sa_family=AF_INET6, sin6_port=htons(55783), inet_pton(AF_INET6,
"xxxxxxxxxxxxxxx", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
[28]) = 3
rt_sigaction(SIGCHLD, {0x80768c0, [], SA_NOCLDSTOP}, NULL, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7e196f8) = 7123
close(3)                                = 0
select(6, [4 5], NULL, NULL, NULL)      = 2 (in [4 5])
select(6, [4 5], NULL, NULL, NULL)      = 2 (in [4 5])
select(6, [4 5], NULL, NULL, NULL)      = 2 (in [4 5])

The last lines (select() call) is then repeated infinitly and the rsync
daemon is no more usuable (until i restart it).

I paste my rsync configuration :

motd file = /etc/rsyncd.motd
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
uid = nobody
gid = nobody
use chroot = yes
timeout = 5
max connections = 15
syslog facility = local5


[xxxxxxxxxxxxxx]
path = /srv/web/xxxxd
comment = xxxxxxxxxx
read only = yes
list = yes


Any help will be appreciated :)

Cheers,

Maxence
-- 
Maxence DUNNEWIND
Contact : maxence@dunnewind.net
Site : http://www.dunnewind.net
02 23 20 35 36
06 32 39 39 93
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url :
http://lists.samba.org/archive/rsync/attachments/20090112/df64d1b4/attachment.bin

On Mon, 2009-01-12 at 13:29 +0100, Maxence DUNNEWIND
wrote:
> Anyway, after it has been working well for some time (between 2 and
> 24hours), the rsync daemon crashes.
I wouldn't call an infinite loop a crash, but whatever.
> It is still running but seems to
> retry something infinitly.
> 
> The rsync log doesn't outputs anything before the crash (just the log
of
> mirrors sync). I 'straced' the rsync process and have the following
> outputs :
> 
> select(6, [4 5], NULL, NULL, NULL)      = 1 (in [5])
> accept(5, {sa_family=AF_INET, sin_port=htons(37870),
sin_addr=inet_addr("xxxxxxxxxxxx")}, [16]) = 3
> rt_sigaction(SIGCHLD, {0x80768c0, [], SA_NOCLDSTOP}, NULL, 8) = 0
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7e196f8) = 7117
> close(3)                                = 0
> select(6, [4 5], NULL, NULL, NULL)      = 1 (in [4])
> accept(4, {sa_family=AF_INET6, sin6_port=htons(55783), inet_pton(AF_INET6,
"xxxxxxxxxxxxxxx", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
[28]) = 3
> rt_sigaction(SIGCHLD, {0x80768c0, [], SA_NOCLDSTOP}, NULL, 8) = 0
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7e196f8) = 7123
> close(3)                                = 0
> select(6, [4 5], NULL, NULL, NULL)      = 2 (in [4 5])
> select(6, [4 5], NULL, NULL, NULL)      = 2 (in [4 5])
> select(6, [4 5], NULL, NULL, NULL)      = 2 (in [4 5])
> 
> The last lines (select() call) is then repeated infinitly and the rsync
> daemon is no more usuable (until i restart it).
I see what happened here: incoming connections arrived on two different
sockets at the same time, and the select call wasn't prepared to handle
that case.  I'll submit a patch.

-- 
Matt