[systemd-devel] early mounts in systemd

[Luca Boccassi]

On Fri, 30 Apr 2021 at 16:45, Rick Winscot <rick.winscot at gmail.com> wrote:
>
> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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.
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.

If you mount your /var via mount units/fstab generator, then
RequiresMountsFor=/var/log/journal will take care of the ordering
automagically.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210430/17429072/attachment-0001.htm>