Re: [systemd-devel] Shutdown behavior follow up
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
Re: [systemd-devel] Shutdown Behavior
Jay Burger schrieb am 13.01.2020 um 17:36 in Nachricht <9f4dc083-18f7-ba68-cc96-1d3c9492e...@us.fujitsu.com>: ... Personally, I would think the initial shutdown should always be honored. Unrealistic dramatized example: I have another emergency at Chernobyl and need to power down my reactor. Oops some service failed while in the shutdown state and the system just rebooted ? china syndrome. Maybe consider looking at it as an elevation type of thing. Lowest level ? reboot higher level ? halt highest level ? poweroff ... Actually I don't think that one of the above is better than another: If you want to reboot a remote system, and the system powers down instead, you may be in trouble as you'll have to "visit" the machine to power it up again. Ulrich I agree, that would not be the best idea and would have to be left to the application. The "elevation" concept was just a thought. My two major concerns are: 1. Once the first shutdown command is underway always honor that. 2. The system state while shutting down should always be "stopping", no matter what system state the shutdown was triggered from. I would actually prefer to not have any options - first shutdown cmd wins and is taken to completion. After all there should not be that many services trying to control how a system shuts down and if there are then I would argue your system might be a little too complex. -Jay -- Subject: Digest Footer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-2Ddevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=aHT4O0VbS7QqrPMUeXCxuLxYDh9qhFEaxzXt-prM39k&s=T4LXhnYYM8z-PJErKqJP8bNdfbbckZeaC9C3GlbTHB4&e= -- End of systemd-devel Digest, Vol 117, Issue 23 ** ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown behavior
On 1/13/20 7:12 AM, systemd-devel-requ...@lists.freedesktop.org wrote: Send systemd-devel mailing list submissions to systemd-devel@lists.freedesktop.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-2Ddevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=3kb3utxeE3bLsnPTvylgDdhJw1Lu_ypUHKgeOojrvA4&e= or, via email, send a message with subject or body 'help' to systemd-devel-requ...@lists.freedesktop.org You can reach the person managing the list at systemd-devel-ow...@lists.freedesktop.org When replying, please edit your Subject line so it is more specific than "Re: Contents of systemd-devel digest..." Today's Topics: 1. Re: Shutdown behavior (Dave Howorth) 2. Re: reformat partition when device is in emergency mode (Belisko Marek) 3. Antw: systemd.mount creating mount resource (What) for bind mounts (Ulrich Windl) 4. Antw: Re: Q: "Start request repeated too quickly." for dependency (Ulrich Windl) 5. Antw: reformat partition when device is in emergency mode (Ulrich Windl) 6. Antw: Re: Shutdown behavior (Ulrich Windl) 7. Antw: Re: Antw: Re: Service fails to start with no log messages (Ulrich Windl) -- Message: 1 Date: Mon, 13 Jan 2020 12:18:00 + From: Dave Howorth To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Shutdown behavior Message-ID: <20200113121800.338bc...@acer-suse.lan> Content-Type: text/plain; charset=US-ASCII On Mon, 13 Jan 2020 11:32:37 +0100 Lennart Poettering wrote: 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... Personally, I would think the initial shutdown should always be honored. Unrealistic dramatized example: I have another emergency at Chernobyl and need to power down my reactor. Oops some service failed while in the shutdown state and the system just rebooted - china syndrome. Maybe consider looking at it as an elevation type of thing. Lowest level - reboot higher level - halt highest level - poweroff I could see a useful option to allow an elevation of shutdown but not a reduction and if a poweroff is the first trigger, period end of story. 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
Re: [systemd-devel] Shutdown behavior
On Mon, 13 Jan 2020 11:32:37 +0100 Lennart Poettering wrote: > 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... 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@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
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
