<div dir="ltr">We have an embedded product that uses a minimal Linux distribution generated via Buildroot.<br><br>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 read-write.<br><br>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. <br><br>Getting /var mounted in proximity to the initialization of systemd-journald.service seemed illusive.<br><br>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.<br><br>My question for anyone on the list, is the method outlined below a reasonable solution to mounting /var early in the start-up cycle?<br><br>Or... is there a better way? Some trimming <br><br><br>Step One: Create a systemd service that mounts /var to the specified partition<br>Service:  /etc/systemd/system/var.service<br><br>[Unit]<br>Description=service for mounting /var<br>DefaultDependencies=no<br><br>[Service]<br>Type=oneshot<br>RemainAfterExit=yes<br>ExecStart=/bin/mount /dev/mmcblk0p6<br><br><br>Step Two: Add a nofail mount<br>fstab:    /etc/fstab<br><br>/dev/root / auto rw 0 1<br>/dev/mmcblk0p6 /var ext4 rw,nofail 0 0<br><br><br>Step Three: Add a wants dependency on the mount in udev triggers (some lines deleted for brevity)<br>Service:    /usr/lib/systemd/system/systemd-udev-trigger.service<br><br>[Unit]<br>...<br>Wants=systemd-udevd.service var.service<br><br>[Service]<br>...<br>ExecStart=udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger<br><br><br>Finally, systemd-analyze plot shows that the mount works as desired.<br><br>systemd-udev-trigger.service<br>    var.service<br>        dev-mmcblk0p6.device<br>            var.mount<br>            ....<br>            systemd-remount-fs.service<br>            systemd-journal-flush.service<br>                local-fs-pre.target<br>                ....<br></div>