Running a service *just* before unmounting filesystems

[hdegoede@xxxxxxxxxx (Hans de Goede)]

Hi,

On 11-06-18 13:31, Lennart Poettering wrote:
> 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?

There are 2 flags / grub environment variables in play here:

boot_success
shutdown_success

The idea being that we also want to show the grub menu if the
system did not shutdown cleanly (or somewhat cleanly given
that by the time we know we really have a clean shutdown we
can no longer write the grubenv).

E.g. the system hangs and the user presses the power-button for
4 seconds.

The feedback I've been getting on the fedora-devel list is that
people are somewhat worried about not being able to get to the
grub menu, so we are being very careful here and err-ing on the
side of showing the menu too often, rather then possibly not
often enough.

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

Right Fedora still uses a regular fstab entry for the ESP and changing
that is out of scope for what I'm working on.

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

See above, currently this is for Fedora Workstation only, and the plan
is actually to do set boot_success from the systemd user session
(using pkexec with a user on console check to execute a new grub2-set-bootflag
binarty which only supports changing a limited no env variables),
so that we know that the user has actually logged in successfully
before setting the flag.

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

So something like this would make sense for server / container
scenarios but not really for Fedora WS, if gdm starts but the
keyboard is not functional so the user cannot log in we still
want to show the menu the next boot so that the user can say
try an older kernel.

And even in server / container scenarios ideally asserting
success would come from a service which checks that say a http
connection can be made or whatever depending on the role of
the server...

###

I cannot help but notice that you've not answered my original
question. So given that the plan is to have both a boot_success
and a shutdown_success flag how would you go about implementing
the service for this?

As explained my current plan is a grub_shutdown.service which gets
added to /lib/systemd/system/poweroff.target, etc. and has a:

Before=umount.target

But I'm thinking about also adding a:

After=shutdown.target

Which I think you won't like, in which case I can live with just
the Before=umount.target but I wonder what your thoughts are on
this?

Regards,

Hans