Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having a problem with my web server: when it's been up for a long time, and then it goes down for some reason, it takes forever to boot.

My workaround to this was to create a cron to reboot the server from time to time (I've been insulted for this, be kind). The reboot was so fast that the server was able to respond to the requests before they timed out, so I was cool with it.

But now I've been told that what might be causing this is fsck being forced after X days, and also after Y mounts, so my fix won't help much.

So the question is what should I do with fsck? Force it to run more frequently, or disable it? Can it run at any time, or it must be during boot? An example of how to do it with tune2fs is also welcome.

share|improve this question
You should really investigate what takes so long to boot. Arch uses systemd, and systemd has a utility called systemd-analyze. I can do systemd-analyze blame and find out what takes so long. Perhaps Ubuntu's upstart has a similar tool. – thirtythreeforty Nov 19 '12 at 18:32
up vote 3 down vote accepted

To answer the easiest question first: Checking a filesystem "at any time" (i.e., when the system is running) is referred to as "online" checking, and in general, it isn't supported. The reason is simple: when a filesystem is mounted, the kernel is doing arbitrary things to the actual block device--which is fine, because it keeps track of what it's doing. But when you throw fsck into the mix, it too messes with the raw block device and doesn't inform the kernel about what it's doing. So they essentially step on each other's toes when making changes to the disk, and you end up with a corrupted filesystem. Even if you just "check" in read-only mode, the results fsck returns will be meaningless, again because fsck has no idea what the kernel is doing.

To change the frequency the filesystem is checked when you mount it, you will use tune2fs, as you mentioned. Suppose you'd like to fsck every 30 reboots. Do

# tune2fs -c 30 /dev/sdaX

(Substitute the block device for your filesystem.)

Or, if for some reason you'd like to disable mount-count-based checking entirely,

# tune2fs -c 0 /dev/sdaX

If you'd rather check on a calendar, you can use -i. For example, to check every week, do

# tune2fs -i 1w /dev/sdaX

You can use d for days, w for weeks, and m for months. Again, to disable calendar-based checking, give a value of 0 for the interval. Please, please, please don't disable all checking. You will, at some point, corrupt your filesystem.

In general, you can get away with slightly longer intervals if the filesystem is journaled, although it isn't a replacement. For more info, read the man pages for e2fsck and tune2fs; they're where I got most of the info for this. Hope this helps!

share|improve this answer
Thanks. But how, with all this, can I make sure that I won't have a slow boot after a crash? (I'm worried about crashes because they usually happen on visits spikes. Add a slow boot to that and I'm screwed) I guess I just need to coordinate a programmed reboot and fsck. But how? Say I program it to run weekly. And I also have a cronjob to reboot weekly. How do I make them happen at the same time? – ChocoDeveloper Nov 19 '12 at 22:21
Also, will running fsck frequently make it faster? Or it's always the same? – ChocoDeveloper Nov 19 '12 at 22:23
As for my first question here, I think I got it: after setting it to 1w, I can use -l to find the exact date. So I just have to make the reboot cron trigger after that date. Am I right? But they may get out of sync if tune2fs adds a week to the last time fsck was run, instead of the last time fsck became enabled to run on the next boot. – ChocoDeveloper Nov 19 '12 at 22:53
The speed of a fsck depends upon the size of the data being checked (not the partition size; there's a difference); additionally, finding a lot of errors will slow it down a bit. If you could split up your data onto several partitions and then stagger the fscks then each one would complete faster. As for your last question, if you set the fsck interval to something like 6d, then when you rebooted every week via cron, the check would be guaranteed to run. – thirtythreeforty Nov 21 '12 at 17:57

Change you scheduled reboot to have one of the following included

touch /forcefsck; reboot


shutdown -rF now

The existence of the /forcefsck will tell the OS to scan the disks (I am pretty sure this is what the second command does anyway.

Use cron to schedule this for a period when the server has the least load and disable the other scheduled scans (date / number of mounts) once you are confident it is running correctly.

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.