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

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

Steve Lord schrieb:
> 
> On Tue, 2002-03-19 at 10:44, Simon Matter wrote:
> n
> >
> > It was on the same partition. I also used to copy the files from
> > /root/xinetd.d/ to /etc/xinetd.d and just rebooted after and no zeros.
> > But I can reproduce it now very easily.
> >
> > ntsysv (en/disabling rsh) ; reboot                 : gives zeroed files
> > ntsysv (en/disabling rsh) ; sleep 40 ; reboot      : is okay.
> >
> > I'm sure ntsysv does something 'interesting' here but from my
> > understanding it should not be possible to damage the FS in such way. It
> > seems to me that somehow bdflush does not update the changes ntsysv did.
> >
> 
> ntsysv does a synchronous transaction in the kernel you have - which in
> itself is not a problem. What appears to be happening is that the
> remount readonly is not doing its job, or log recovery is for some
> reason thinking the filesystem was not cleanly unmounted - which
> might (just might) have something to do with the raid1 root partition.

I know it's not only ntsysv because I found /root/.bash_history filled
with zeros.

> 
> So, can you see if you are getting a message about running recovery
> during bootup:
> 
> XFS mounting filesystem sd(8,1)
> XFS: WARNING: recovery required on readonly filesystem.
> XFS: write access will be enabled during mount.
> Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1)
> Ending XFS recovery on filesystem: sd(8,1) (dev: 8/1)

There was not a single log recovery as far as messages goes back. So the
filesystem was shutdown properly (metadata) but data was not written?

I modified /etc/rc.d/init.d/halt in the section before killall like this

# Try to sync
sync
sync
sync
sync
sync

and got no zeroed files!

My next idea was using xfs_freeze because the man page says

Using the -f option, the filesystem is locked out from new
modifications, write system calls are halted on entry, other calls which
modify the filesystem are halted at the start of a transaction, all
ongoing transactions in the filesystem are allowed to complete.

I removed the sync's and tried this just before the remount readonly:

runcmd $"Freezing root file systems: " xfs_freeze -f /
runcmd $"Unfreezing root file systems: " xfs_freeze -u /

But this was a bad idea because it has frozen the kernel :-)

Now I'm thinking about the sync. I tried with just one sync with no
success. I remember that with HP/UX and Solaris we were always used to
issue sync several times. IIRC I read somewhere that we don't have to do
this on linux but in my case it seems to help.

Does it make sense to put something like this into the shutdown script

# Syncing Filesystems
sync ; sleep 1 ; sync ; sleep 1 ; sync ; sleep 1 ; sync

> 
> This should not happen after a clean shutdown. If this is happening,
> then is it possible to bring a system up on a different root, or in
> some other way run xfs_logprint -t on the filesystem before it is
> mounted again?

Do you want me to run xfs_logprint -t even after a clean shutdown?

-Simon