[systemd-devel] Running a service *just* before unmounting filesystems

[Lennart Poettering]

On Mo, 11.06.18 12:48, Hans de Goede (hdegoede at redhat.com) wrote:

> Hi All,
> 
> So as you may have heard, I'm working on hiding the grub-menu
> by default on single OS Fedora Workstation.  Part of the plan
> here is to detect if a previous boot was successful and
> cleanly shutdown the machine and show the menu (not hide the
> menu) if the previous boot has failed to set either the
> boot_success or shutdown_success flags:
> 
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
> 
> So now I'm working on writing a unit file which will
> be added to poweroff.target.wants, reboot.target.want,
> etc. and which will call:

Uurks. Quite frankly, it appears strange to me to delay this for this
long. I mean we reworked most code that delayed worked to shutdown
like this these days to happen as early as possible to make sure we
don't lose state unnecessarily. For example the RTC syncing is
generally done when the RTC is changed instead of synced back during
shutdown. Hence, why not simply write this out when the boot is
successful?

Note that /boot or /efi is very likely an automount point, (that's at
least how we recommend things to be set up, as this provides the best
guarantees that the ESP remains is a clean state, as it will be very
quickly after the last access, and hence only be in dirty state during
a very short timeframe around accesses), and in that case "right
before unmount" doesn't make much sense in general, as that would be
pretty much all the time (that said, I don't think fedora/Anaconda
makes use automount points for /boot and /esp, or even systemd's
auto-discovery of the ESP currently, they haven't seen the light there
yet, but they really really should)

Hence, my recommendation would be: write a small service that is
pulled in by default.target, but orders itself after it. Then make
your changes from there. i.e. do it as final steps during boot, rather
than delay it to shutdown.

note that there have been plans of introducing some generic framework
for such "boot completion" tests, as it is useful for a number of
usecases, for example Atomic would like to use that. Such a framework
would be very minimal most likely: add a new generically named target,
before which all "is all good" checkers would be ordered, and after
which all "mark the boot as successful" servers ared ordered. Your
grub service would fit in perfectly in the latter then.

Would love to take a patch adding that generic concept!

Lennart

-- 
Lennart Poettering, Red Hat