I have a co-lo server I've been maintaining for a few years now running IDE drives on a mostly terrible UPS. A few months ago, when it returned from a power outage (running 6.2-R) I started noticing the following in my daily security email: Checking setuid files and devices: find: /var/db/portsnap/files/2dc95ddff37a8091239e83bf7e3ce5a2c285b027891ced1919d76c9947c5b7db.gz: Bad file descriptor find: /var/db/portsnap/files/52abe8c91385b12272f13f4d20896067d9ba70bdec1fa2575025858bd3e93718.gz: Bad file descriptor find: /var/lost+found/#238237: Bad file descriptor I verified that these files return the same result when trying to do any operation on them (including ls in the directory). I've managed to ignore the problem for a while now, and even upgraded to 7.2, but I'm not sure if it will cause problems later on. So the question is, without access to the console, how would I fix this? - Pat
Tuesday 12 May 2009 20:10:57 Pat Wendorf napisa?(a):> I have a co-lo server I've been maintaining for a few years now running IDE > drives on a mostly terrible UPS. A few months ago, when it returned from a > power outage (running 6.2-R) I started noticing the following in my daily > security email: > > Checking setuid files and devices: > find: > /var/db/portsnap/files/2dc95ddff37a8091239e83bf7e3ce5a2c285b027891ced1919d7 >6c9947c5b7db.gz: Bad file descriptor > find: > /var/db/portsnap/files/52abe8c91385b12272f13f4d20896067d9ba70bdec1fa2575025 >858bd3e93718.gz: Bad file descriptor > find: /var/lost+found/#238237: Bad file descriptor > > I verified that these files return the same result when trying to do any > operation on them (including ls in the directory). > > I've managed to ignore the problem for a while now, and even upgraded to > 7.2, but I'm not sure if it will cause problems later on. So the question > is, without access to the console, how would I fix this?I think tere is a need for fsck on this partition. /var is used by many daemons for logging, mailqueue etc., so maybe the first thing to do would be to stop as many daemons as possible and leaving only ssh to get to this system remotely? I really don't know how much dangerous could be unmounting /var on a live system in such case. -- Pozdrawiam, Maciej Milewski
on 13/05/2009 23:46 Andrew Snow said the following:> Pat Wendorf wrote: >> I spoke too soon I guess: A buddy of mine at the hosting provider took >> down >> the box and did a fsck -y on the var partition, this seems to have >> cleaned >> it up. It looks like the regular fsck -p could not repair it. > > > You may like to put fsck_y_enable="YES" in your /etc/rc.conf, though > this does not affect the root volume.This would make fsck -y run on all filesystems (clean, just checked, always ro, etc) iff fsck -p fails. This can be dangerous too if filesystem state is such that fsck gets confused. -- Andriy Gapon