22.02.2020 22:50, jay.bur...@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
> Sent: Monday, January 13, 2020 4:33 AM
> To: Burger, Jay
> Cc: systemd-devel@lists.freedesktop.org; Dang, James
> ; Berger, Daniel ;
> Mahabaleshwar, Niranjan
> Subject: Re: [systemd-devel] Shutdown behavior
>
> 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
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
