xfs
[Top] [All Lists]

Re: files in /etc/xinetd.d become 0 byte size

To: Simon Matter <simon.matter@xxxxxxxxxxxxxxxx>
Subject: Re: files in /etc/xinetd.d become 0 byte size
From: Juri Haberland <juri@xxxxxxxxxxxxxx>
Date: Wed, 20 Mar 2002 19:24:28 +0100
Cc: Steve Lord <lord@xxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxx>
Organization: totally unorganized
References: <Pine.LNX.4.33.0203190839410.19919-100000@xxxxxxxxxxxxxxxxxxxxxxxx> <3C97591 B.FF456D25@xxxxxxxxxxxxxxxx> <3C975DB7.4010201@xxxxxxxxxxxxxx> <3C9760EA.3874D744@xxxxxxxxxxxxxxxx> <1016554052.4383.4.camel@xxxxxxxxxxxxx s.sgi.com> <3C976ADD.FE0E7CDA@xxxxxxxxxxxxxxxx> <1016558028.1770.31.camel@xxxxxxxxxxxxxxxxxxxx> <3C978B5E.3040309@xxxxxxxxxxxxxx> <1016565408.1770.93.camel@xxxxxxxxxxxxxxxxxxxx> <3C979839.5378CCA1@xxxxxxxxxxxxxxxx> <1016568031.1841.132.camel@xxxxxxxxxxxxxxxxxxxx> <3C98C002.3F3815F2@xxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020305
Simon Matter wrote:
> Steve Lord schrieb:
>> 
>> On Tue, 2002-03-19 at 13:57, Simon Matter wrote:
>> > Steve Lord schrieb:
>> > >
>> > > On Tue, 2002-03-19 at 13:02, Juri Haberland wrote:


>> > > > Simon
>> > > > what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might
>> > > > not be a good choice...
>> >
>> > You want me to cry, not a good choice, I have contributed them :-)
>> > Serious, I'll try a newer kernel as soon as I can.
>> 
>> We are just trying to eliminate variables here - not blaming your
>> merging skills. Juri appears to have a similar setup, except he
>> does not see the problem with a recent kernel.
> 
> I've just tried to make a joke after a frustrating day...

I thought about checking who contributed this kernel RPMS before sending
that mail but was to lazy ;)

> I have checked out 2.4.18-xfs from CVS 8 hours ago. Compiled and tested
> and I can confirm the problem is gone. Of course I don't know whether
> the problem comes from the 1001 RedHat patches or the kernel or XFS
> itself.
> 
> Now, I can not upgrade all servers to 2.4.18 and even if I could, I
> didn't have time to test it very well so I have to stick with the RH
> 2.4.9-31 kernel for now (in production). The solution is to modify the
> /etc/rc.d/init.d/halt script to call sync several times, BEFORE the
> umount -a. If I sync just before remounting / ro, it does not help.

I'm not convinced that 'sync' is the solution. As I can see from your
script you do a loop with several 'sync; sleep 1'. Maybe a 'sleep 30' -
as you tested successfully in another mail - would be sufficiant...

> Would be nice if someone could put this into FAQ since it affects all
> installaions from the RedHat installer at least on software raid.

Are you sure anbout that? Is it really happening with a stock
installation without *any* kernel upgrade?
If I find the time during the weekend I will do some tests with the
latest official SGI kernel release as well as with all following
contributed kernels. Maybe we can narrow it down to a specific release...

Juri


<Prev in Thread] Current Thread [Next in Thread>