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