Re: Shutdown behavior

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 10.01.20 10:56, Jay Burger (jay.burger@xxxxxxxxxxxxxx) wrote:

> I made the same type of change in the emergency_action() function in v232.
>
> Question 1: Would this be considered a problem with the design, needing an
> upstream fix? Or would this be considered a particular user issue, to be fixed with
> an isolated patch, like we have done? If the latter is the answer to this
> then would
> this be considered a legit fix for our purposes? Or is there a better way to handle
> this use case? I know fixing my user services to not fail on the shutdown would be
> preferable, but pulling teeth is not in my skillset.

Hmm, so what is the expected behaviour here? If one service requires a
reboot and another a poweroff, and one is triggered first and the
other second, then I can at least think of four policies that make
sense:

1. first requested always wins

2. last requested always wins

3. reboot is the positive outlook, and thus always wins

4. poweorff is the positive outlook, and thus always wins.

Unless I am mistaken we currently implement policy 2. Which one would
you prefer? Can you make a good case why it would be better in the
general case?

I have the suspicion we should just adopt the best possible policy
here and stick to it and not make things needlessly configurable. But
it's a matter of discussion which one that is...

> Question 2: I recently found a case where a poweroff shutdown was triggered
> while the system was in the "starting" state and a service failure occurred during
> the shutdown. In this case my logic change did not prevent the shutdown from
> changing to a reboot. This check of the manager_state found the state was still
> "starting" and the poweroff was again changed to a reboot. Is there a
> different logic
> path taken when in the starting state as opposed to the running state?

Not really, no.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel