[systemd-devel] Shutdown behavior

[Jay Burger]

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