1

I'm encountering an issue with a systemd service starting before a local partition is mounted, particularly after a power loss event. I've investigated and found that this problem arises due to a system reboot and subsequent fsck operation.

To easily replicate the problem, I've created a minimal proof of concept. Here are the details.

I have a systemd service called test.service with the following configuration:

[Unit]
Description=fsck order POC
After=network-online.target local-fs.target remote-fs.target swap.target

[Service]
ExecStart=/bin/bash -c "date > /mnt/storage/hello"

[Install]
WantedBy=multi-user.target

In my /etc/fstab, I've configured a mount point as follows:

/dev/sda1 /mnt/storage auto nosuid,nodev,nofail 0 2

Running sudo tune2fs -l /dev/sda1 | grep -i "mount count" returns:

Mount count: 1
Maximum mount count: 1

This indicates that /dev/sda1 undergoes fsck at every boot. However, the hello file is created in the root filesystem's /mnt/storage directory instead of the expected sda1 mount point.

As a result, I don't see anything in /mnt/storage after booting. However, I can see the hello file if I umount /mnt/storage.

My question is: What changes should I make in test.service to ensure that my script is executed after all filesystems are mounted and checked? (Note: The mount point's name might vary, as I don't have control over it when deployed at a client's site.)

The system is running Ubuntu. This problem does not happen on Debian.

Any insights or suggestions on resolving this issue would be greatly appreciated. Thank you in advance for your assistance!

5
  • Change this /dev/sda1 /mnt/storage auto nosuid,nodev,nofail 0 2 to this /dev/sda1 /mnt/storage auto nosuid,nodev,nofail 0 1. Take note of the 1 instead of the 2 at the end.
    – paladin
    Feb 20 at 9:49
  • From man fstab : The sixth field (fs_passno). This field is used by fsck(8) to determine the order in which filesystem checks are done at boot time. The root filesystem should be specified with a fs_passno of 1. Other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. Defaults to zero (don’t check the filesystem) if not present. So I should use 2. And even with 1, it doesn't change anything.
    – matt
    Feb 20 at 10:18
  • PS you can use mount to check if a filesystem is mounted, like so (example, adjust to your needs) test "$(grep /dev/sda1 /proc/mounts | head -n1)" = "/dev/sda1 /srv ext4 rw,noexec,relatime 0 0" && echo "true" || echo "false"
    – paladin
    Feb 20 at 10:22
  • Have you tested it? Checking the root filesystem is different from checking non root filesystems.
    – paladin
    Feb 20 at 10:24
  • Yes tested with the 1 value, sadly this does not work.
    – matt
    Feb 20 at 10:39

1 Answer 1

1
solution from my comment

from systemd.mount manpage:

nofail
            With nofail, this mount will be only wanted, not required,
 by local-fs.target or remote-fs.target. Moreover the mount unit is not ordered
 before these target units. This means that the boot will continue without
 waiting for the mount unit and regardless whether the mount point can be 
 mounted successfully.

if you try without that flag , local-fs.target

first attempt to help (didn,t was a solution in this case)

Run:

systemctl list-units --type=mount

Identify your mount-unit, and add it to After= in your systemd-file.

Maybe helpful to identify the correct unit:

systemctl status <unit>
3
  • If I had After=mnt-storage.mount, the file is created on the right place. but this doesn't entirely solve my problem since clients may use exotic mount points. I would like to wait until all mount points are active.
    – matt
    Feb 20 at 10:38
  • 1
    from systemd.mount manpage: nofail With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. Moreover the mount unit is not ordered before these target units. This means that the boot will continue without waiting for the mount unit and regardless whether the mount point can be mounted successfully. if you try without that flag , local-fs.target should take effect
    – 43n12y
    Feb 20 at 11:06
  • You're right, it comes from this option. If you edit your original post, I can mark it as the accepted answer.
    – matt
    Feb 20 at 14:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .