<div dir="ltr">On Fri, 30 Apr 2021 at 16:45, Rick Winscot <<a href="mailto:rick.winscot@gmail.com">rick.winscot@gmail.com</a>> wrote:<br>><br>> 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>> _______________________________________________<br>> systemd-devel mailing list<br>> <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a><br>> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><div><br></div><div>You don't need to synchronize with the actual journald unit - you need to synchronize with systemd-journal-flush.service which is what moves the journal from /run/log to /var/log.</div><div>The default flush unit is ordered with systemd-tmpfiles-setup which is also somewhat early-boot - what I do is mask systemd-journal-flush.service, and provide my own without that ordering constraint.</div><div><br></div><div>If you mount your /var via mount units/fstab generator, then RequiresMountsFor=/var/log/journal will take care of the ordering automagically.</div></div>