2021-04-30 14:39:23 UTC
generated via Buildroot.
Early in the project it was decided to make the rootfs read-only... in an
effort to improve durability in environments where power fluctuations might
cause problems on the eMMC. At the same time, making logging (e.g. /var)
persistent for debugging was added to requirements. Persistent storage
would be achieved by mounting /var to a separate partition that is
Several-hundred hours later... with many systemd-analyze reports and
various configurations tested, we have determined that managing the /var
mount with stadard services is not going to work due to tightly coupled and
precisely timed dependencies. Attempts with /etc/fstab and the systemd
generator are also unstable.
Getting /var mounted in proximity to the initialization of
systemd-journald.service seemed illusive.
Several days ago I found a post on Stackoverflow that tied into udev
triggers that seemed promising; resulting in the method outlined below.
Initial testing shows proper timing with all dependencies satisfied.
However, the solution feels... hackey.
My question for anyone on the list, is the method outlined below a
reasonable solution to mounting /var early in the start-up cycle?
Or... is there a better way? Some trimming
Step One: Create a systemd service that mounts /var to the specified
Description=service for mounting /var
Step Two: Add a nofail mount
/dev/root / auto rw 0 1
/dev/mmcblk0p6 /var ext4 rw,nofail 0 0
Step Three: Add a wants dependency on the mount in udev triggers (some
lines deleted for brevity)
ExecStart=udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm
Finally, systemd-analyze plot shows that the mount works as desired.