xfs
[Top] [All Lists]

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

To: Juri Haberland <juri@xxxxxxxxxxxxxx>
Subject: Re: files in /etc/xinetd.d become 0 byte size
From: Steve Lord <lord@xxxxxxx>
Date: 19 Mar 2002 13:16:48 -0600
Cc: Simon Matter <simon.matter@xxxxxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxx>
In-reply-to: <3C978B5E.3040309@xxxxxxxxxxxxxx>
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>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Tue, 2002-03-19 at 13:02, Juri Haberland wrote:
> 
> Ok, when you mentioned the SW RAID1 root partition I remembered that I
> have a similar box sitting here. It's also a fresh SGI-RH7.2
> installation with all updates and all partitions are on a SW-RAID1, but
> on SCSI disks, not on IDE disks.
> 
> I ran three test like yours (ntsysv (en/disabling time ; reboot)) and
> afterwards I still had all files in /etc/xinetd.d with their proper
> contents. I also had my .bash_history.
> This box runs a 2.4.18-xfs-smp kernel from CVS, checked out on 4th of March.
> 
> Simon
> what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might
> not be a good choice...

I agree with Juri on the try a recent kernel. And Simon, to answer your
other question, if recovery is not reported as being run - then no need
to look with xfs_logprint, the problem is the remount readonly code.

Steve

> 
> Juri
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


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