[systemd-devel] Shutdown behavior

[Dave Howorth]

On Mon, 13 Jan 2020 11:32:37 +0100
Lennart Poettering <lennart at poettering.net> wrote:
> On Fr, 10.01.20 10:56, Jay Burger (jay.burger at 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...

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel