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 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 email@example.com https://lists.freedesktop.org/mailman/listinfo/systemd-devel