Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

File system corruption

1 view
Skip to first unread message

Pat Wendorf

unread,
May 12, 2009, 2:10:57 PM5/12/09
to
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
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

Maciej Milewski

unread,
May 13, 2009, 5:24:16 AM5/13/09
to
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

Ivan Voras

unread,
May 13, 2009, 8:46:26 AM5/13/09
to

Not critically dangerous - it can be done with care. Of course, it's
best to reboot afterwards :)

signature.asc

Pat Wendorf

unread,
May 13, 2009, 4:37:09 PM5/13/09
to
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.

2009/5/13 Maciej Milewski <mi...@dat.pl>

Andriy Gapon

unread,
May 14, 2009, 9:02:45 AM5/14/09
to
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

0 new messages