Control systemd File-System Quota Checks at Boot

You will learn when systemd-quotacheck.service runs, how to inspect the installed unit, and how to select its boot-time mode. The practical result is a quota check that is either automatic, deliberately forced, or deliberately skipped, with a way to verify which decision was applied. Allow about 15 minutes for inspection. Changing the kernel command line needs a maintenance window because it affects the next boot.

1. Confirm the installed systemd version

This guide is written against the Ubuntu package installed on this machine: systemd 255.4-1ubuntu8.17, reporting upstream systemd 255. The local manual describes the same three modes used below. Exact status wording and boot-generator details can differ in later releases, so check the installed manual before copying this into a fleet runbook.

$ systemd --version
systemd 255 (255.4-1ubuntu8.17)

The helper is not normally on a user's PATH. The installed service calls /usr/lib/systemd/systemd-quotacheck directly. You do not need to run that helper by hand. It is part of the system boot sequence and expects systemd's environment and ordering.

2. Inspect the unit without changing it

Read the unit and its manager state before considering a boot override. These commands are ordinary read-only inspection and normally need no elevated privileges:

$ systemctl cat systemd-quotacheck.service
$ systemctl show systemd-quotacheck.service \
    -p LoadState -p ActiveState -p UnitFileState -p FragmentPath
LoadState=loaded
ActiveState=active
UnitFileState=static
FragmentPath=/usr/lib/systemd/system/systemd-quotacheck.service

The unit is static, not a service you enable in the usual way. Its file declares a oneshot service that remains active after its command exits, runs after local file systems have been mounted, and is ordered before remote file systems and shutdown. The manual says it is pulled in only when at least one file system has quotas enabled. Therefore, an absent or inactive-looking quota check can be the correct result on a host with no enabled quotas.

Do not edit /usr/lib/systemd/system/systemd-quotacheck.service. Package upgrades replace vendor unit files, and changing the unit is not how the check mode is selected.

3. Check whether the current boot selected a mode

The setting is a kernel command-line parameter, not a systemd service option. Inspect the current boot's command line as an unprivileged user:

$ tr ' ' '\n' < /proc/cmdline | grep '^quotacheck\.mode=' || echo 'no explicit quota-check mode'
no explicit quota-check mode

No matching line means the helper uses its default, auto, for this boot. This command does not prove that a quota check was needed. It only answers whether an explicit mode was supplied.

4. Choose the least surprising mode

The available values are:

• auto asks the file-system quota checker to decide whether checking is necessary. This is the default and is the normal choice.
• force requests a full file-system quota check, even when the checker would otherwise decide that one is unnecessary. This can extend boot time and should be scheduled rather than added casually.
• skip suppresses file-system quota checks for that boot. Use it only when you understand the risk to quota accounting and have a specific operational reason.

These values are mutually exclusive. Do not add several quotacheck.mode= parameters and expect the result to be obvious. Keep one explicit value, or remove the parameter and return to auto.

5. Apply a one-boot override

At the bootloader menu, edit the selected Linux entry for one boot and append one of these parameters to the existing kernel command line:

quotacheck.mode=auto
quotacheck.mode=force
quotacheck.mode=skip

The exact keystroke used to edit a boot entry depends on the bootloader, so do not turn this temporary test into a persistent configuration change by accident. A one-boot edit normally affects only the next boot. After the machine starts, repeat the command from step 3 and confirm the value actually reached the kernel.

For example, a forced boot should show:

$ tr ' ' '\n' < /proc/cmdline | grep '^quotacheck\.mode='
quotacheck.mode=force

6. Verify the service and inspect failures

After boot, check the unit state and its journal. The first command is read-only. Access to the complete system journal may require sudo on a locked-down host:

$ systemctl status systemd-quotacheck.service --no-pager
$ sudo journalctl -b -u systemd-quotacheck.service --no-pager

Look for whether the unit was loaded and whether its start completed successfully. A skipped unit, a unit not pulled in because no quota-enabled file system exists, and a unit that failed while checking are different cases. Do not treat active (exited) alone as proof that every quota file is correct; it only describes the oneshot service's completed state.

If the service failed, preserve the journal output and identify the affected file system before retrying. Rebooting repeatedly with force can turn a storage problem into a longer outage. Investigate the underlying quota configuration and the separate quotacheck(8) documentation before running a manual repair.

7. Undo a temporary decision

To return to the normal behaviour, remove quotacheck.mode=force or quotacheck.mode=skip from the boot entry before the next boot. If you made the change persistent in a bootloader configuration, remove that exact parameter using the bootloader's normal configuration method, then rebuild its menu only if that method requires it. Confirm the recovery with:

$ tr ' ' '\n' < /proc/cmdline | grep '^quotacheck\.mode=' || echo 'auto mode is in effect'
auto mode is in effect

There is no service-level undo command because the mode belongs to the kernel command line. Restoring the command line restores the default decision process.