Crash report....still not working
Spicer, Kevin
Kevin.Spicer@bmrb.co.uk
Mon, 29 Apr 2002 10:04:11 +0100
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1EF5C.D3E451F0
Content-Type: text/plain;
charset="iso-8859-1"
Thanks for your reply. I'm not 100% sure my fix has solved it as it failed
again over the weekend, however I put a wrapper script around rdiff-backup
--server on the remote machine to ulimit on that too & it has worked so far
(but only two days)
I'm actually backing up a data-drive, so there are no device files in the
heirachy, I'm guessing /dev/zero is used internally by rdiff-backup or
rdiff?
-----Original Message-----
From: Ben Escoto [mailto:bescoto@stanford.edu]
Sent: 29 April 2002 06:44
To: Spicer, Kevin; rdiff-backup@keywest.Stanford.EDU
Subject: Re: Crash report....still not working
>>>>> "KS" == Kevin Spicer <Spicer>
>>>>> wrote the following on Fri, 26 Apr 2002 09:44:17 +0100
KS> I believe that I have now fixed this - it appears to have been
KS> caused by a limit of 64 on the maximum number of file
KS> descriptors. Fixed it by adding ulimit -n unlimited to the
KS> start of my cron job.
Well, I'm glad it works now for you, but I still don't see why
rdiff-backup would have opened more than 64 files simultaneously.
KS> etc... I still have no idea what is causing this (although it
KS> might be helpful to know that the directories I'm backing up
KS> have lots and lots of small files (e.g. many at 50 / 60 bytes)
rdiff-backup seems to handle these situations ok. Maybe it is a
Solaris thing, though.
KS> open(/dev/zero): Too many open files libthread panic:
KS> alloc_chunk (PID: 4565 LWP 1)
Why does the error always happen on /dev/zero? This can't be
coincidence? Device file handling hasn't been well tested on
non-linux systems, so if the problem is with /dev/zero maybe
--exclude-device-files would help (or --exclude /dev/zero :-)).
It seems you've also encountered a bug when trying to resume a
previous backup? I will look into it..
--
Ben Escoto
BMRB International
http://www.bmrb.co.uk +44 (0)20 8566 5000
____________________________________________________________
This message (and any attachment) is intended only for the recipient and may
contain confidential and/or privileged material. If you have received this
in error, please contact the sender and delete this message immediately.
Disclosure, copying or other action taken in respect of this email or in
reliance on it is prohibited. BMRB International Limited accepts no
liability in relation to any personal emails, or content of any email which
does not directly relate to our business.
------_=_NextPart_001_01C1EF5C.D3E451F0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Crash report....still not working </TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Thanks for your reply. I'm not 100% sure my fix =
has solved it as it failed again over the weekend, however I put a =
wrapper script around rdiff-backup --server on the remote machine to =
ulimit on that too & it has worked so far (but only two =
days)</FONT></P>
<P><FONT SIZE=3D2>I'm actually backing up a data-drive, so there are no =
device files in the heirachy, I'm guessing /dev/zero is used internally =
by rdiff-backup or rdiff?</FONT></P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ben Escoto [<A =
HREF=3D"mailto:bescoto@stanford.edu">mailto:bescoto@stanford.edu</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: 29 April 2002 06:44</FONT>
<BR><FONT SIZE=3D2>To: Spicer, Kevin; =
rdiff-backup@keywest.Stanford.EDU</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Crash report....still not working =
</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>>>>>> "KS" =3D=3D Kevin =
Spicer <Spicer></FONT>
<BR><FONT SIZE=3D2>>>>>> wrote the following on Fri, 26 =
Apr 2002 09:44:17 +0100</FONT>
</P>
<P><FONT SIZE=3D2> KS> I believe that I have now fixed this - =
it appears to have been</FONT>
<BR><FONT SIZE=3D2> KS> caused by a limit of 64 on the maximum =
number of file</FONT>
<BR><FONT SIZE=3D2> KS> descriptors. Fixed it by adding =
ulimit -n unlimited to the</FONT>
<BR><FONT SIZE=3D2> KS> start of my cron job.</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>Well, I'm glad it works now for you, but I still =
don't see why</FONT>
<BR><FONT SIZE=3D2>rdiff-backup would have opened more than 64 files =
simultaneously.</FONT>
</P>
<P><FONT SIZE=3D2> KS> etc... I still have no idea what =
is causing this (although it</FONT>
<BR><FONT SIZE=3D2> KS> might be helpful to know that the =
directories I'm backing up</FONT>
<BR><FONT SIZE=3D2> KS> have lots and lots of small files =
(e.g. many at 50 / 60 bytes)</FONT>
</P>
<P><FONT SIZE=3D2>rdiff-backup seems to handle these situations =
ok. Maybe it is a</FONT>
<BR><FONT SIZE=3D2>Solaris thing, though.</FONT>
</P>
<P><FONT SIZE=3D2> KS> open(/dev/zero): Too many open files =
libthread panic:</FONT>
<BR><FONT SIZE=3D2> KS> alloc_chunk (PID: 4565 LWP 1)</FONT>
</P>
<P><FONT SIZE=3D2>Why does the error always happen on /dev/zero? =
This can't be</FONT>
<BR><FONT SIZE=3D2>coincidence? Device file handling hasn't been =
well tested on</FONT>
<BR><FONT SIZE=3D2>non-linux systems, so if the problem is with =
/dev/zero maybe</FONT>
<BR><FONT SIZE=3D2>--exclude-device-files would help (or --exclude =
/dev/zero :-)).</FONT>
</P>
<P><FONT SIZE=3D2> It seems you've also encountered a =
bug when trying to resume a</FONT>
<BR><FONT SIZE=3D2>previous backup? I will look into it..</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Ben Escoto</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>BMRB International </FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.bmrb.co.uk" =
TARGET=3D"_blank">http://www.bmrb.co.uk</A> +44 (0)20 8566 5000 </FONT>
</P>
<P><FONT =
SIZE=3D2>____________________________________________________________ =
</FONT>
<BR><FONT SIZE=3D2>This message (and any attachment) is intended only =
for the recipient and may contain confidential and/or privileged =
material. If you have received this in error, please contact the sender =
and delete this message immediately. Disclosure, copying or other =
action taken in respect of this email or in reliance on it is =
prohibited. BMRB International Limited accepts no liability in relation =
to any personal emails, or content of any email which does not directly =
relate to our business.</FONT></P>
</BODY>
</HTML>
------_=_NextPart_001_01C1EF5C.D3E451F0--