Sometimes my web server crashes, and it may take hours to boot. I've been told fsck might be the culprit, because it can only be run during boot, only runs after X days and Y mounts, and if the server was up for a lot of time, on the next reboot it will for sure be slow.

So what can I do to fix this? I found about tune2fs. But I will need to coordinate that with a reboot cronjob? Say I do tune2fs -i 1w /dev/sda1. I'm afraid that if I set a cron to run after that date (which I can get with -l), on the following dates they will be out of sync, won't they?

Another thing that is not clear: after a crash, will fsck run anyway no matter what? Should it? Will it still be slow, even if it was run less than a week ago?


tl;dr: Take a look at your system logs, or use something like bootlogd, this should show you where the slow down is occurring. My bet would be that it is not fsck.

Firstly, fsck can run whenever, it doesn't have to run at boot. What you're probably referring to is that it can only run on an unmounted filesystem, and since / and other filesystems are mounted when the system is fully operational, that is the only possible time to run it on those filesystems.

fsck should not take hours to complete if it is merely doing a regular check, unless it actually finds inconsistencies in the filesystem and has to fix them (but even then, an hour sounds highly unlikely, even on a large filesystem with numerous inconsistencies). Take a look at your system logs, or use something like bootlogd, this should show you where the slow down is occurring. My bet would be that it is not fsck.

Filesystems can develop inconsistencies without any noticeable side effects, that's the purpose of the regular fsck checks regardless of whether the filesystem is marked dirty.

You cannot unmount your root filesystem whilst the system is running, as it will be in use, therefore you cannot run fsck on it, so there is no way to properly run a cron job to do it. It would be possible to force a fsck on a reboot on certain dates, and then reboot, but I don't really see the point. I don't really understand what you mean by being "out of sync".

After a crash, fsck will run on any dirty filesystems, that is, filesystems that were not cleanly unmounted. If your computer was to crash during normal operation, therefore, yes, fsck would run. If your computer crashed at the very final stage of shutdown, probably not, as the filesystems would not have been compromised.

  • "I don't really understand what you mean by being "out of sync"" I mean that if I set it to run 1w, then check the date and it says eg: Sun 20 05:00:00, then set a cron to reboot weekly starting on Sun 20 05:01, fsck will run on say Sun 20 05:01:02, and its next date will be Sun 27 05:01:02. I think that's how it works, and will get out of sync with the reboot cron. – ChocoDeveloper Nov 19 '12 at 23:29
  • @ChocoDeveloper That filesystem flag to fsck is just that, a flag. It won't run weekly, it will be flagged to run weekly. That is, if you don't remount the filesystem, that week flag becomes irrelevant. fsck looks at the flag when it runs, but it will only run when the filesystem becomes available -- in your case, when you reboot. – Chris Down Nov 19 '12 at 23:31
  • Yes I understand that. I set it to run weekly and I also set a cron to reboot weekly. – ChocoDeveloper Nov 19 '12 at 23:31
  • @ChocoDeveloper To avoid this issue altogether, you might want to use the > /forcefsck method, that is, create a file at /forcefsck and fsck will be forced to run on the next reboot. You could do that just before you reboot. – Chris Down Nov 19 '12 at 23:33
  • My guess was that if errors get acumulated on the disk, rebooting and running fsck frequently would prevent a terribly slow boot after a crash. – ChocoDeveloper Nov 19 '12 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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