Safely verify systemd-remount-fs.service after filesystem changes

You will finish with a read-only check of systemd-remount-fs.service, a way to compare configured and active mount options, and a cautious procedure for deciding whether a remount is justified. The examples match systemd 255.4-1ubuntu8.17, the installed package version on this machine.

Allow about 15 minutes. You need a shell, access to the machine's systemd manager, and a recent change or question about /etc/fstab, the root filesystem, /usr, or a kernel API filesystem such as /proc. The inspection steps are read-only. Do not run the remount action on a production host until you understand which mount will change.

1. Check the service without changing anything

Start by asking systemd for the unit state:

systemctl status systemd-remount-fs.service --no-pager

On the reference machine, the useful part of the result is:

Active: active (exited) ...
Main PID: ... (code=exited, status=0/SUCCESS)

This is a oneshot service. It performs its work and exits, while RemainAfterExit=yes keeps the unit recorded as active. Do not treat an exited main process as a failure. The unit is also normally pulled in during early boot, before the local filesystem targets.

2. Confirm the unit and its scope

Read the installed unit file as an ordinary user:

systemctl cat systemd-remount-fs.service

For this package, the service runs /usr/lib/systemd/systemd-remount-fs as a oneshot. Its purpose is narrow: it applies options for the root filesystem, /usr, and virtual kernel API filesystems. It does not process ordinary data mounts such as a separate /home or a removable disk.

The configuration sources are /etc/fstab and, when the relevant generator is active, partition-table data used by systemd-gpt-auto-generator. If no relevant configuration exists, the service does nothing. That makes a successful unit state compatible with unchanged mount options.

Inspect the fstab entries without editing them:

findmnt --fstab --evaluate --output TARGET,SOURCE,FSTYPE,OPTIONS

Then look at what the kernel currently reports:

findmnt --output TARGET,SOURCE,FSTYPE,OPTIONS / /usr /proc /sys /dev

Some of those paths may be absent or combined on your host. That is normal. Compare only targets that exist, and remember that findmnt --fstab reads configuration while the second command reports mounted state.

3. Check the specific option you changed

Do not compare two large, wrapped listings by eye if one option is the concern. Ask for a single target, replacing the example path with the filesystem you actually changed:

findmnt --output TARGET,SOURCE,FSTYPE,OPTIONS /

For a root entry, the output should contain one row whose TARGET is /. For a change to /usr, use:

findmnt --output TARGET,SOURCE,FSTYPE,OPTIONS /usr

Options such as ro, rw, noexec, nodev and nosuid are properties of the active mount. A matching line in /etc/fstab alone does not prove that the running mount has adopted it. Conversely, an option inherited from an earlier mount or an initrd may explain why the live result differs from a quick reading of the file.

4. Inspect a failure with elevated access only when needed

Read the service journal next. The command itself is ordinary, although some journal entries may require elevated access on a locked-down system:

journalctl -u systemd-remount-fs.service --no-pager -b

If the output says that entries were skipped because your user cannot read the journal, repeat only that inspection with sudo:

sudo journalctl -u systemd-remount-fs.service --no-pager -b

Look for a bad option, an unavailable device, a permission problem, or an entry that does not describe the mount you intended. Keep the original error. A remount can fail because the kernel or filesystem rejects an option even when the syntax in /etc/fstab looks plausible.

If the unit is failed and you have just corrected /etc/fstab, validate the file and inspect the generated view before considering a retry:

findmnt --verify --verbose

findmnt --verify checks the fstab configuration. It does not make a broken entry safe, and it does not apply changes. Fix one clearly identified entry at a time, then repeat the read-only checks.

5. Decide whether a manual remount is safe

For a boot-time correction, the lower-risk operational choice is usually to fix and verify /etc/fstab, then schedule a reboot during an approved maintenance window. If you must test a live change, first record the output from step 3, ensure you have console or out-of-band recovery, and make sure the intended option is supported by the mounted filesystem.

Only an administrator should run a live retry:

sudo systemctl restart systemd-remount-fs.service

Immediately verify the result and inspect the journal:

systemctl status systemd-remount-fs.service --no-pager
findmnt --output TARGET,SOURCE,FSTYPE,OPTIONS / /usr
sudo journalctl -u systemd-remount-fs.service --no-pager -n 50

If the retry made the situation worse, stop using further remount attempts. Restore the known-good /etc/fstab entry, use the recorded before-state to identify the affected target, and reboot through your normal recovery procedure if the root or /usr mount is no longer usable. For an ordinary data filesystem, use that filesystem's documented mount procedure rather than assuming this service controls it.

6. Avoid the common traps

• Active does not mean universal. The service can be successful while an unrelated data mount remains unchanged.
• One service run is not a live configuration guarantee. A later mount, container, or namespace can have different state.
• /etc/fstab may not be the only input. GPT auto-discovery and the fstab= kernel command-line setting can affect whether fstab-generated units are present.
• Do not edit generated units. Inspect the unit with systemctl cat, then change the source configuration that is actually wrong.