Re: reboot forcing a fsck

Jim Pazarena <fquest@paz.bz> writes:
> I have a server which seems to have a fs issue for my exim folder.
> an "ls -l" hangs. anything going near the exim folder hangs - for
> whatever reason.

You say that `ls -l <path>` hangs.  In addition to reading the directory
itself, `ls -l` reads the metadata of every directory entry and sorts
them by name.  This can take a long time if there is a large number of
entries.  To avoid this, and make sure you're only running ls itself and
not an alias or an alternate implementation, use `/bin/ls -a <path>` to
get a plain listing.  If that works and no entries appear to be
corrupted, try `ktrace -f /tmp/ktrace.out /bin/ls -al <path>`.  If that
hangs, running `kdump -f /tmp/ktrace.out -tcn | tail` in another
terminal will tell you where it's stuck.

> If I trigger a 'reboot', I assume the boot process will automatically
> enter a fsck as per the documentation.
>
> What is unclear is if the system will eventually g et to multi-user
> mode, or hang at a CLI question from the fsck?

Assuming UFS with soft updates (`sysctl -n kern.features.softupdates`
should print 1), you can run `fsck_ffs -B <mountpoint>` to perform
limited checks on a mounted filesystem without rebooting.

You can also add the following to /etc/rc.conf to force a more thorough
fsck on reboot:

    background_fsck_enable="no"
    fsck_flags="-fy"

Beware that this can take a long time.  You will want to revert these
changes (especially fsck_flags) once the situation is resolved.

DES
-- 
Dag-Erling Smørgrav - des@FreeBSD.org