>>> Lennart Poettering <lenn...@poettering.net> schrieb am 13.01.2020 um 11:32 >>> in Nachricht <20200113103237.GD5149@gardel-login>: > 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.
5. The one that completes first, 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? Essentially that i 5) if it ever succeds ;-) > > 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? In older SUSE Linux (pre-systemd), the first Ctrl+Alr+Del sometimes hung, but a second one succeeded then. I can't tell whether the second trigger just unblocked the first restart request, or whether the second restart request just "overtook" the first one, however... But still, the first one to complete, wins... Regards, Ulrich _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
