systemd 247 /etc/systemd/journald.conf storage is persistent, systemd-journal-flush.service has RequiresMountsFor=/var/log/journal.
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. On Fri, Apr 30, 2021 at 11:45 AM Michael Biebl <[email protected]> wrote: > 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 > <[email protected]>: > > > > 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 > > [email protected] > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel >
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
