server crash when running rsync --daemon

Jorg B. jorg_b at cwo.com
Sun Feb 2 09:17:53 EST 2003


This problem is occurring on two different servers, with completely different 
hardware, different version of slackware and different version of kernel 
(tried on 2.4.18, 2.4.19 and 2.4.20).

There is nothing major in common between the 2 servers except proftpd and 
rsync.

We have done some extensive trouble shooting but everything runs for days 
without a problem until we start rsync.

Any more ideas ?

JB



On Saturday 01 February 2003 14:07, you wrote:
> On Sat, Feb 01, 2003 at 01:47:39PM -0800, Jorg B. wrote:
> > Hello,
> >
> > We are running rsync version 2.5.6 on a slackware (version 9.0-beta)
> > linux server. This server is basicly a ftp server (96 sessions max) and a
> > rsync (rsync --daemon) server (25 connections max).
> >
> > The server keeps on crashing and after many ours of hardware/software
> > trouble shooting the crashes appear to be related to the rsync processes.
> >
> > If I turn off rsync --daemon the server runs fine for days... after I
> > turn rsync back on the server crashes (freezes) within 5 minutes without
> > any logs or indications on what caused the crash.
> >
> > I've read that there is a know memory issue on directory trees that are
> > fairly large... could this be the reason.
> >
> > Here's some info about the machine...
> >
> > Slackware Linux (kernel 2.4.20)
> > Adaptec P2-B Motherboard
> > Pentium III - 500Mhz
> > Adaptec Dual channel Ultra 160 scsi adapter with 10,000 RPM IBM scsi
> > drives. 512MB of RAM
> >
> > Here is a copy of the rsyncd.conf file:
> >
> > ftp:/etc# cat rsyncd.conf
> > max connections = 25
> > syslog facility = daemon
> > #socket options = SO_KEEPALIVE
> > read only = yes
> > list = yes
> > uid = nobody
> > gid = nobody
> > timeout = 180
> >
> > [blah]
> >         comment = blah
> >         path = /home/ftp/pub/files
> >
> > Does anybody have any idea on what the problem may be ?
>
> Most likely you have a hardware problem.
>
> When user-mode code causes a system to crash it is the
> system that is at fault, not the user-mode code.  rsync is
> known for its ability to stress the system.  Either you have
> a hardware problem or you are experiencing a bug in the
> 2.4.20 kernel.
>
> I assume the system had been running OK for some time and
> that this is a new problem.
>
> Start by looking in the system logs for anything suspicious.
> Be especially alert to disk and interrupt errors.  Run
> memtest86, preferably overnight.  While doing that you might
> check to see if there are any known issues with 2.4.20 and
> your hardware or in general (check out kernelnewbies).  If
> you still don't find anything ask on kernelnewbies or lkml
> following the procedures indicated on kernelnewbies.



More information about the rsync mailing list