On Mon, 13 Jan 2020 11:32:37 +0100 Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > 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... Surely this is application-dependent? I can conceive of applications that require reboot (or at least best efforts at it), and others that require shutdown. For the first, consider a system controlling something dangerous. If the system is forced down by some watchdog, it most likely should reboot and try again. For the second, consider a system whose power is supplied via a UPS and has just been informed the UPS is about to run out of power. Whatever it does, it's going down and its best policy is likely to shutdown/hibernate such that it can restart when power returns. Is there not a case to at least provide a hook so that some application-specific code can make the decision? But certainly, I think that a service failing during shutdown should not affect the outcome of that shutdown. Having some broken service decide whether or not I can shut my machine down is ridiculous. > > 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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel