<div dir="ltr">systemd 247<div><br></div><div>/etc/systemd/journald.conf storage is persistent, systemd-journal-flush.service has RequiresMountsFor=/var/log/journal.</div><div><br></div><div>Mounting /var on a separate read-write partition handles the persistent log requirement as well as offloading other read-write operations that can no longer live on the rootfs... being read-only.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 30, 2021 at 11:45 AM Michael Biebl <<a href="mailto:mbiebl@gmail.com">mbiebl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What is the actual problem you have with a separate /var and systemd-journald?<br>
For completeness sake, which systemd version do you have?<br>
<br>
Am Fr., 30. Apr. 2021 um 16:39 Uhr schrieb Rick Winscot<br>
<<a href="mailto:rick.winscot@gmail.com" target="_blank">rick.winscot@gmail.com</a>>:<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" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div>