[systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

[Lennart Poettering]

On Fri, 10.10.14 11:55, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:

> 
> On 10/10/2014 09:20 AM, Lennart Poettering wrote:
> >  rule that if two
> >units are ordered against each other, and one is started and one is
> >stopped the stop will always be executed first, the start second,
> >regardless if the actual ordering is After= or Before=
> 
> Yeah sure but there is a different between units that have been run ( thus
> started and or stopped either at boot up, by specific custom target and or
> manually ) and those that have never been run
> ( which for example is the case with all the units that are tied to the
> shutdown.target )
> 
> 
> If I add shutdown-test.service to the After= line of the httpd.service it
> still does not get executed in the right order at shutdown
> 
> And
> 
> If I add Before=httpd.service to the shutdown-test.unit it still is not
> execuded in the right order at shutdown.

Not following here. Ordering deps and requirement deps are fully
orthogonal in systemd. If you want to pull something in, it needs to
be pulled in explicitly, just the ordering won't have any effect on
its own.

And this is good that way, because otherwise enabling/disabling would
have no effect on this.

> From my perception the logic and thus the brokeness in the design seems to
> be due the fact that the ordering ( After=, Before= ) of units which have
> never been run are not being taken into account when atleast the
> shutdown.target is being run. ( Have not tested this with custom targets to
> see if those are affected as well )
> 
> 
> >. Now, this
> >means unless you want to run your code only after some other service
> >shut down, everything is good. But if you want your code to run before
> >some other unit is shut down, then you cannot express this with a
> >service that is started at shutdown.
> ...
> >
> >Thus the recommended way to implement services that are execute right
> >at the appropriate place in the shutdown order is to make it a service
> >that is a NOP at start, and only contains ExecStop=.
> 
> To me this is a workaround which should not be needed or necessary and is
> due to what I consider the brokeness of the design ( or the implementation
> of that design ).

Well, so, there's more to this scheme. Before we install a transaction
in our execution queue we check it for ordering cycles and if we find
one we refuse the transaction. This some relatively simple graph
theory. It's easy to do as long as we keep the ordering relation
between start and stop jobs very very simple. It's not that easy
though if we need to look for cycles not only between start/start,
stop/stop, start+stop/stop+start but also when introducing two
different kinds of ordering between start and stop of two units.

When Kay and I discussed this graph theory problem back when we wrote
the code we came to the conclusion it was much simpler to simply
implement the current rules and require that services that shall just
execute at shutdown, but not at startup should do so by including an
empty ExecStart= but a populated ExecStop=.

I am pretty sure the status quo makes a ton of sense if you look at
the maths behind it. 

Lennart

-- 
Lennart Poettering, Red Hat