Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Usually, fsck it is executed automatically at startup after n reboots. Sometimes it can be really slow and delays the computer startup in more than 30 minutes.

Is there any way to run fsck at shutdown instead? (I don't mind if shutdown is delayed, boot time is more important)

By the way, I want it for Debian or Scientific Linux distros.


share|improve this question

3 Answers 3

While you can check some things, during shutdown, you cannot run fsck effectively for your root filesystem. fsck requires that the filesystem is not mounted before it can attempt repair. This is only possible during boot, while still running from initramfs.

share|improve this answer
You're right. I hadn't thought of that. – Diego Herranz Feb 28 '13 at 12:01

For Debian you can use AutoFsck but the package is no longer supported (last update 2010). So keep that in mind.

The other way would be to put a FSCK/bash script in your shutdown script. For SE linux/centos etc I would use chkconfig level 0 (halt) and 6(reboot). chkconfig --levels 0 rc.local-shutdown on Put the script in /etc/rc.d/init.d/. (level 6 for reboot)

For Debian I would put the create the scripts in /etc/rc6.K00scriptname and /etc/rc0.d/K00scriptname,

As for the script, you can use something like this:


if (( `tune2fs -l /dev/sda2 | awk '/Mount count/{print $3}'` > `tune2fs -l /dev/sda2 | awk '/Maximum mount count/{print $4-1}' ))
then /sbin/fsck -A -T -C -a -t $NETFS 2>/dev/null

This code was not written by me, but by someone on archlinux forums. I have not tried the code. So keep that in mind too.

Or you can just do something simple like /sbin/fsck -A -T -C -a -- -f inside the script.

share|improve this answer

The problem with fsck on shutdown is that, you see when you are shutting down, you are unmounting the filesystem. Even if the fs is dirty, unmounting a fs doesn't force it to check it's integrity. While, you are mounting it, you are performing a fsck to check whether the metadata for the data is correct and whether fs has proper information for the fs as it reports it has. This can take place while the fs is going to be mounted. Because the code to check the fs integrity comes to play when the fs is going to be mounted.

This is I would guess the reason that we can do a lazy umount even if the fs is dirty but there is no lazy or forced umount when the fs is dirty ;)

Usually journalling fs shouldn't take long time to come up unless it is heavily screwed. xfs_repair is pretty slick and can be done online while btrfs is well, another story.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.