Re: reboot forcing a fsck

On Mon, 18 Mar 2024 14:08:08 -0700, Jim Pazarena wrote:
> 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 you find any strange messages in the "dmesg" output
or in /var/log/messages?



> If I trigger a 'reboot', I assume the boot process will automatically
> enter a fsck as per the documentation.

Depends on the setting in /etc/rc.conf. If you have
enabled a background fscj, which probably is already
the default, strange things can happen, up to booting
in a somehow inconsistent FS environment.

The setting

	background_fsck="NO"

is something I consider essential. Booting into an
environment where some filesystem checks are performed
on a live filesystem that is in use and assuming everything
is okay is... not okay, in my opinion.



> What is unclear is if the system will eventually g et to multi-user
> mode, or hang at a CLI question from the fsck?

The fsck process will start automatically at system
startup for all file systems listed in /etc/fstab in
case they are not marked CLEAN, which is how a normal
system shutdown should have left them. If there is a
minor problem, fsck will repair it without interaction.
Severe problems that _might_ lead to data loss are
brought to the administrator's attention and require
interaction. It could even be possible that you need
to perform a second fsck run, the system will inform
you if that is needed.

All this happens before the system starts its network
services.




> I have no hands or eyes available to be there. This is a bare metal
> chassis not a vm.

What kind of access do you have? Does it require a
SSH session of the system in question to be accessible,
or do you have a means to connect to a serial console
of said system.



> Would appreciate learning the procedure which fsck uses during a boot.
> (beyond what the man fsck advises) which seems to exclude this question.

Read "man fsck" carefully, especially on the implications
of -f and -y. Also keep in mind that system functionality
depends on how you've organized your partitions (so for
example, if /home is damaged and on a separate partition
or even disk, but the rest is okay, things could be easier
to check and solve).

Examine the _actual_ problem, then reach for the appropriate
tools. Those might require work at a low level, but in many
cases, will save you from a full re-install or scary forensic
data retrieval sessions. ;-)


--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...