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

[Simon Matter <simon.matter@ch.sauter-bc.com>]

Juri Haberland schrieb:
> 
> 
> > 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...

You're completly right, I have just tested it. The sync call doesn't
help anything and a single sleep ?? is enough.

> 
> > 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?

I have just tried 2.4.9-13SGI_XFS_1.0.2 from the 7.2 installer CD and
it's all the same. So I guess every RH XFS Kernel until
2.4.9-31SGI_XFS_1.0.2 suffers the bug.
If it is just a timing issue then maybe your system needs more time to
shutdown because you have other services running and that's why you
don't have the problem. I can reproduce it on three completely different
kind of hardware.

The good news: Eric is building updated kernel RPMs and this bug is
fixed there.

> 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