Starting a service at shutdown time, with requirements

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Di, 20.03.18 15:36, Colin Walters (walters at verbum.org) wrote:

> 
> 
> On Tue, Mar 20, 2018, at 3:25 PM, Lennart Poettering wrote:
> > On Di, 20.03.18 15:09, Colin Walters (walters at verbum.org) wrote:
> > 
> > > Another way I've thought about handling this is to basically invert things so that
> > > we have a "stub" unit that starts on bootup, and its ExecStop does
> > > the real work:
> > 
> > This is the correct and recommended way to do this.
> 
> Thanks!
> 
> > I think it's relatively pretty, as it means you have to "start"
> > something explicitly so that it can run code at shutdown. I'd claim
> > this is a semantical benefit, not a malus.
> 
> Right.  It does make sense also to me that basically we want to
> "hold a reference" to any resources required (in this case the /sysroot mount).
> 
> But so `halt-local.service` is just busted?  I guess no one really cares
> that much about it today, I may see though about submitting a PR to add
> a warning not to use it as a model.

So basically, during shutdown there's this moment of singularity,
where we switch from "negative" operation to "positive" operation,
i.e. where we switch from *stopping* running stuff and move into
*starting* the final shutdown code. The halt-local.service stuff as well
as systemd-poweroff.service and similar are among the latter.

Of course, you can decide to plug in your stuff into that phase of the
boot too, but if so you can't really have any deps anymore, you are
basically running with *everything* already turned off. And in most
cases this is not what you want: you actually want some stuff around
still, for example in your case sysroot.mount and suchlike.


Lennart

-- 
Lennart Poettering, Red Hat