Running a service *just* before unmounting filesystems

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Di, 12.06.18 11:33, Hans de Goede (hdegoede at redhat.com) wrote:

> > I figure gdm could
> > try to expose that feature somewhere, maybe in the top-right menu or
> > so?
> 
> Yes I need to talk to the GNOME designers about adding some advanced
> reboot options somewhere:
> 
> 1) Reboot into firmware setup
> 2) Show boot menu next menu
> 
> Any others?

I wouldn't know any.

> I'm thinking myself to do something like what Windows does (assuming
> that will help with discoverability) where shift + click on reboot shows
> this menu.

Makes sense.

> > I figure if there's need for it we could even have some mini daemon
> > whose only job is to provide a reboot-into-firmware hotkey during
> > early boot time. i.e. something that just listens to some otherwise
> > silent keycombo (maybe shift+alt+ctrl), and when it's pressed within
> > the first minute of bootup we'll instantly reboot into firmware or
> > so... In theory that could even be systemd-logind (which already
> > watches input devices for SW_DOCK and SW_LID events), but logind is
> > started quite late, hence maybe a seperate mini daemon might be
> > wise...
> 
> Hmm, how soon during boot is the ctrl+alt+up target available ?

as soon as PID 1 initialized, and that includes the initrd if the
initrd runs systemd (and fedora's does).

> We could add a .service file there which forces showing the grub
> menu next time (and the grub menu will also allow entering
> firmware).

That's an option, indeed.

> > > If I understand correctly systemd will start all services under:
> > > /lib/systemd/system/system-update.target.wants one by one and
> > > the service to mark the boot indeterminate should exit with an
> > > error since it is not the one handling the updates (that is fine),
> > > but if the actual update service runs before us then we won't
> > > run.
> > > 
> > > I could modify all the services under /lib/systemd/system/system-update.target.wants
> > > with an ExecStartPre to call grub2-editenv but I would prefer
> > > a generic solution, any suggestions here ?
> > 
> > Not sure I follow. I mean, setting the state to "indeterminate" should
> > happen whenever the offline update operation succeeded, no? If the
> > offline update operation fails then this should be counted as a bad
> > boot, no? As such your little plugin should run after
> > system-update.target, exactly like in the default.target regular boot
> > case?
> 
> AFAIK the service actually doing the updates is supposed to call
> systemctl reboot --force when it is done, so any targets after
> system-update.target won't get started ?

True, the service in question could split the reboot call of course,
if it wanted, so that you can plug things in between.

Lennart

-- 
Lennart Poettering, Red Hat