[systemd-devel] Shutdown behavior follow up

[Andrei Borzenkov]

22.02.2020 22:50, Jay.Burger at fujitsu.com пишет:
> All,
> 
> Referring to my last email regarding the systemd shutdown behavior.  I am working on the assumption that the idea of honoring the first shutdown request
> is the preferred way to go. If not this email can be ignored.
> 
> I have reproduced the same behavior using a fedora 31 machine with systemd v243. I have a proposed fix, including source file change, patch file and sample service
> which can be used to both show the problem and show the fix. I am not sure if this is the right forum to attach those files.

Create pull request on guthub:

https://github.com/systemd/systemd


> 
> If this is the desired behavior, I am wondering  what are my next steps to get this into the next systemd delivery. I have not done this before so I am looking for some instruction?
> 
> Thanks in advance,
> -Jay
> 
> -----Original Message-----
> From: Lennart Poettering <lennart at poettering.net> 
> Sent: Monday, January 13, 2020 4:33 AM
> To: Burger, Jay <Jay.Burger at us.fujitsu.com>
> Cc: systemd-devel at lists.freedesktop.org; Dang, James <James.Dang at us.fujitsu.com>; Berger, Daniel <dan.berger at us.fujitsu.com>; Mahabaleshwar, Niranjan <Niranjan.Mahabaleshwar at us.fujitsu.com>
> Subject: Re: [systemd-devel] Shutdown behavior
> 
> 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...
> 
>> 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
>