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
[systemd-devel] Shutdown behavior
Hi,
I have a couple of questions regarding systemd shutdown behavior.
I first noticed this behavior using systemd v213, I am now on v232
and see the same problem. I found a fix in 213 and patched
the service.c module, in 232 the change needed to move to the
emergency-action.c module.
The problem I have is my system has a number of services that
have been setup as FailureAction=Reboot and during a shutdown
one or more of these services fail triggering the FailureAction.
If the shutdown was a poweroff, this failure triggers systemd to
add the SPECIAL_REBOOT_TARGET into the job queue which ends up
changing my poweroff to a reboot. This also occurs with the initial
shutdown being a halt, the result is a reboot. I am working on other
developers to fix their services to not crash and burn during a
shutdown but in the meantime I need to make sure the original shutdown
reason is maintained.
It appears that systemd is not keeping track of the fact that a
particular shutdown is in progess. In which case it should ignore
any subsequent shutdowns that may get triggered while going down.
The logic that I changed in service.c was in the service_execute_action()
function. The case for SERVICE_FAILURE_ACTION_REBOOT, I added a
call to get the manager_state() as follows:
+ state = manager_state(UNIT(s)->manager);
+ if( state != MANAGER_STOPPING ) {
+ r = manager_add_job_by_name(UNIT(s)->manager, JOB_START,
+ SPECIAL_REBOOT_TARGET, JOB_REPLACE,
+ true, &error, NULL);
+ if (r < 0)
+ log_error_unit(UNIT(s)->id,
+ "Failed to reboot: %s.",
bus_error_message(&error, r));
+ } else {
+ log_info("ServiceExeAction: Mgr already stopping");
+ }
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.
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?
Thanks in advance,
-Jay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Startup single step
Lennart/all, Thanks for your quick responses. I tried the systemd.confirm_spawn and got the answer I was expecting. I agree systemd was not built to support this type of operation and the confirm_spawn seems to work(or not) much as one would expect. It seems to reliably fall apart the longer you wait to respond to the prompt. Thanks again, -Jay On 07/03/2019 06:23 AM, Lennart Poettering wrote: On Di, 02.07.19 12:30, Jay Burger (jay.bur...@us.fujitsu.com) wrote: Hi, I am curious if there is a way to single step through the systemd startup of services? So this exists, in theory in systemd.confirm_spawn= on the kernel cmdline. But it's not without pitfalls. In particular, some distros like to forcibly bind some service's stdio to the tty, which then interferes with the asking the user stuff. More importantly though, systemd implements a parallel boot, and a boot that cannot necessarily be linearized (for exampe: a service X that connects to a service Y via socket activation or bus activation necessarily means that X' and Y' start-up need to happen in parallel), and this makes the the interactive boot-up quite complicated to follow. Moreover lots of software tends to apply timeouts to stuff (including systemd), and if we interactively ask the user each time for everything these time-puts are hit easily. For example dbus clients generally wait for 45s at most for connection attempts and method calls, and since things add up these are hit quickly. hence, yes you can do this, but it's not particular fun, and falls apart quickly on complex systems, as such interactive boot-ups tend to behave quite differently from regular ones. Usually it's better to just turn on debug logging, and try to figure out things from the logs, when they happen in the same (non-)order and (rougly) the same timing behaviour as the regular boots. I don't find any such feature and am curious what others would think of it. We had a similar feature in a previous life, different OS, and developers seemed to like it. I personally think it was a handy tool to have in the arsenal, probably not a "use it all the time" kind of thing. It could be triggered via a kernel command line option and in it's simplest form, systemd would start a service and prompt the user before continuing to the next. I know this would change timing and dependencies may have issues but just throwing out the idea. This could possibly even be used to single step through the shutdown of services. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Startup single step
Hi, I am curious if there is a way to single step through the systemd startup of services? I don't find any such feature and am curious what others would think of it. We had a similar feature in a previous life, different OS, and developers seemed to like it. I personally think it was a handy tool to have in the arsenal, probably not a "use it all the time" kind of thing. It could be triggered via a kernel command line option and in it's simplest form, systemd would start a service and prompt the user before continuing to the next. I know this would change timing and dependencies may have issues but just throwing out the idea. This could possibly even be used to single step through the shutdown of services. Thanks in advance for your attention, -Jay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Port 231 security patch to 213
Christian, Found the fix here: https://github.com/systemd/systemd/pull/4240 This seems to work, I no longer have an issue even with the endless loop option used to create the problem. -Jay On 10/24/16 11:11, Christian Hesse wrote: Jay Burger on Mon, 2016/10/24 10:54: Hi, I need some help porting the security patch released in version 231 back to version 213. If this is not the correct place for this question can someone point me to the proper forum? Updating my system from 213 to 231 is not an option for me at this time. If anyone knows if this has been done can you point me to the patch? What exactly are you referring to? Does this help? (There is no v213 tree, but v214 is next.) https://github.com/systemd/systemd-stable/tree/v214-stable ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Port 231 security patch to 213
Christian, I am using a Yocto distribution "daisy" which is on version 211, they have provided recipe updates to what they call systemd 213. I am referring to the patch as discussed on the following site: https://threatpost.com/hack-crashes-linux-distros-with-48-characters-of-code/121052/ This claims the problem began is version 209. I found the systemd-231-security_fix-1.patch on this page but am not sure if it applies. http://www.linuxfromscratch.org/patches/downloads/systemd/ Thanks for your help. -Jay On 10/24/16 11:11, Christian Hesse wrote: Jay Burger on Mon, 2016/10/24 10:54: Hi, I need some help porting the security patch released in version 231 back to version 213. If this is not the correct place for this question can someone point me to the proper forum? Updating my system from 213 to 231 is not an option for me at this time. If anyone knows if this has been done can you point me to the patch? What exactly are you referring to? Does this help? (There is no v213 tree, but v214 is next.) https://github.com/systemd/systemd-stable/tree/v214-stable ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Port 231 security patch to 213
Hi, I need some help porting the security patch released in version 231 back to version 213. If this is not the correct place for this question can someone point me to the proper forum? Updating my system from 213 to 231 is not an option for me at this time. If anyone knows if this has been done can you point me to the patch? Thanks in advance, -Jay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd shutdown behavior
Hi, I have a general question concerning systemd's behavior during systemctl reboot, halt or poweroff. As the system is in the process of shutting down, I am wondering if a service fails during the shutdown process does systemd still honor the restart/reboot behavior defined in that programs service file. For example if a service has defined a restart sequence, will systemd try to restart that service even though it is in the process of shutting down? Same question for a service that has defined a FailureAction=reboot? I am running systemd 213 so maybe this is not the case now, but I have observed behavior that makes me think the answer to both questions is yes, the defined actions are still honored. Thanks in advance, -Jay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-211 patch for FailureAction
Hi, I am a complete newbie to this list and I am trying to find out if I can patch my systemd-211 to include the FailureAction feature. If so where can I obtain the patche(s)? We are using the yocto daisy distribution which has systemd-211 and due to silly process restrictions getting the dizzy version is not going to happen any time soon. Any help is greatly appreciated. -Jay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
