Re: early mounts in systemd

[Michael Biebl <mbiebl@xxxxxxxxx>]

What is the actual problem you have with a separate /var and systemd-journald?
For completeness sake, which systemd version do you have?

Am Fr., 30. Apr. 2021 um 16:39 Uhr schrieb Rick Winscot
<rick.winscot@xxxxxxxxx>:
>
> We have an embedded product that uses a minimal Linux distribution 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 read-write.
>
> 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 partition
> Service:  /etc/systemd/system/var.service
>
> [Unit]
> Description=service for mounting /var
> DefaultDependencies=no
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/mount /dev/mmcblk0p6
>
>
> Step Two: Add a nofail mount
> fstab:    /etc/fstab
>
> /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)
> Service:    /usr/lib/systemd/system/systemd-udev-trigger.service
>
> [Unit]
> ...
> Wants=systemd-udevd.service var.service
>
> [Service]
> ...
> ExecStart=udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger
>
>
> Finally, systemd-analyze plot shows that the mount works as desired.
>
> systemd-udev-trigger.service
>     var.service
>         dev-mmcblk0p6.device
>             var.mount
>             ....
>             systemd-remount-fs.service
>             systemd-journal-flush.service
>                 local-fs-pre.target
>                 ....
> _______________________________________________
> systemd-devel mailing list
> systemd-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel