On Fr, 10.01.20 10:56, Jay Burger (jay.bur...@us.fujitsu.com) 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

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 Poettering, Berlin
systemd-devel mailing list

Reply via email to