Last week I posted a complaint about ncheck getting into an
infinite loop. The original posting will be given below.
So far I have received replies from
cxh@arsenic.berkeley.edu (Christopher Hylands)
dan@diamond.bbn.com (Dan Franklin)
tellab5!vpnet!trdlnk!mike@uunet.UU.NET
The last message said, very succintly,
>Try running fsck on the affected file system (in single user mode, of
course)
This was the key.
Fsck discovered a whole bunch o' files that had problems. After I
let fsck fix them all, the ncheck problem seems to have vanished.
The offending files were created in the /var/spool hierarchy by
nqs, which I have been trying to install recently. It's clear that
I'm going to have to look at nqs more closely. It's also installed
on another machine with no ill effects.
Thanks, everybody!
--------- original posting follows
-------------------------------------
I have a puzzling problem that has been bothering me for a long time.
Every night each of our workstations runs a cron job that does some
elementary security checking (Yes, I know about COPS, thank you.)
including a run of ncheck -s on the local filesystems. On one
workstation, ncheck sometimes goes into an infinite loop, burning
up all available cycles until I kill it by hand.
One of those jobs is running now. According to "trace", it's
repeating these two system calls:
>lseek (3, 999424, 0) = 999424
>read (3, "".., 1024) = 1024
Now fd #3 points to inode 3127 in the root filesystem, which is
local disk partition sd0a. The file associated with inode 3127
is /dev/sd0a.
Now I don't know how to continue. The partition sd0a is about 7.5
MB, so the lseek isn't running off the end. Any ideas what else
I can do?
SunOS 4.1.1. The afflicted machine is a Sparcstation 1+. The
disk is a stock Quantum 105.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:51 CDT