Crash report....still not^H^H^H working
Spicer, Kevin
Kevin.Spicer@bmrb.co.uk
Sat, 11 May 2002 23:36:42 +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_01C1F93C.530E88E0
Content-Type: text/plain;
charset="iso-8859-1"
Quick mail to follow up on this..
My rdiff backup (on Solaris 2.6 if you remember) has now worked reliably for
nearly two weeks after I added...
ulimit -n unlimited
to the start of my cron job and created a wrapper script on the remote
machine which looked like this...
#!/bin/sh
ulimit -n unlimited
rdiff-backup --server
exit
And changed the remote schema on the command line of rdiff-backup to call
the wrapper script rather than rdiff-backup itself on the remote machine.
As for the /dev/zero thing I've done a bit of Googleing and it seems that
/dev/zero is used internally by libthread on Solaris (which doesn't really
explain why its opening more than 64 files - but at least I think I've now
got round it).
Regards
Kevin
-----Original Message-----
From: Ben Escoto [mailto:bescoto@stanford.edu]
Sent: 30 April 2002 03:59
To: Spicer, Kevin; rdiff-backup@keywest.Stanford.EDU
Subject: Re: Crash report....still not working
>>>>> "KS" == Kevin Spicer <Spicer>
>>>>> wrote the following on Mon, 29 Apr 2002 10:04:11 +0100
KS> Thanks for your reply. I'm not 100% sure my fix has solved it
KS> as it failed again over the weekend, however I put a wrapper
KS> script around rdiff-backup --server on the remote machine to
KS> ulimit on that too & it has worked so far (but only two days)
KS> I'm actually backing up a data-drive, so there are no device
KS> files in the heirachy, I'm guessing /dev/zero is used internally
KS> by rdiff-backup or rdiff?
/dev/zero isn't used by rdiff-backup (except when it's being backed
up). I wouldn't have thought that rdiff would use /dev/zero either,
but I asked about this on the rproxy mailing list in case one of them
knows something.
--
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_01C1F93C.530E88E0
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^H^H^H working </TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Quick mail to follow up on this..</FONT>
<BR><FONT SIZE=3D2>My rdiff backup (on Solaris 2.6 if you remember) has =
now worked reliably for nearly two weeks after I added...</FONT>
<BR><FONT SIZE=3D2>ulimit -n unlimited</FONT>
<BR><FONT SIZE=3D2>to the start of my cron job and created a wrapper =
script on the remote machine which looked like this...</FONT>
</P>
<P><FONT SIZE=3D2>#!/bin/sh</FONT>
<BR><FONT SIZE=3D2>ulimit -n unlimited</FONT>
<BR><FONT SIZE=3D2>rdiff-backup --server</FONT>
<BR><FONT SIZE=3D2>exit</FONT>
</P>
<P><FONT SIZE=3D2>And changed the remote schema on the command line of =
rdiff-backup to call the wrapper script rather than rdiff-backup itself =
on the remote machine.</FONT></P>
<P><FONT SIZE=3D2>As for the /dev/zero thing I've done a bit of =
Googleing and it seems that /dev/zero is used internally by libthread =
on Solaris (which doesn't really explain why its opening more than 64 =
files - but at least I think I've now got round it).</FONT></P>
<P><FONT SIZE=3D2>Regards</FONT>
</P>
<P><FONT SIZE=3D2>Kevin</FONT>
</P>
<BR>
<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: 30 April 2002 03:59</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 Mon, 29 =
Apr 2002 10:04:11 +0100</FONT>
</P>
<P><FONT SIZE=3D2> KS> Thanks for your reply. I'm not =
100% sure my fix has solved it</FONT>
<BR><FONT SIZE=3D2> KS> as it failed again over the weekend, =
however I put a wrapper</FONT>
<BR><FONT SIZE=3D2> KS> script around rdiff-backup --server on =
the remote machine to</FONT>
<BR><FONT SIZE=3D2> KS> ulimit on that too & it has worked =
so far (but only two days)</FONT>
<BR><FONT SIZE=3D2> KS> I'm actually backing up a data-drive, =
so there are no device</FONT>
<BR><FONT SIZE=3D2> KS> files in the heirachy, I'm guessing =
/dev/zero is used internally</FONT>
<BR><FONT SIZE=3D2> KS> by rdiff-backup or rdiff?</FONT>
</P>
<P><FONT SIZE=3D2>/dev/zero isn't used by rdiff-backup (except when =
it's being backed</FONT>
<BR><FONT SIZE=3D2>up). I wouldn't have thought that rdiff would =
use /dev/zero either,</FONT>
<BR><FONT SIZE=3D2>but I asked about this on the rproxy mailing list in =
case one of them</FONT>
<BR><FONT SIZE=3D2>knows something.</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_01C1F93C.530E88E0--