We do not go through STOP_POST and for the situations where we do, we do not set the variables we say we will

[evverx]

Based on #4745 (comment)

So we do not go through STOP_POST on service_enter_signal(s, SERVICE_FINAL_SIGTERM, SERVICE_FAILURE_PROTOCOL) and for the situations where we do, we do not set the variables we say we will.
Indeed, this is a divergence from the documentation. However, this divergence was not introduced by the addition of the protocol error type and was already present with the resources error type. I think we should merge this PR as it currently is and start a new issue for the discrepancy between the manpage and the actual fail behavior. This new issue should also address the lack of a line for SERVICE_RESULT=protocol in the table at https://www.freedesktop.org/software/systemd/man/systemd.exec#$EXIT_CODE.

[joukewitteveen]

This problem is manifest in several places in src/core/service.c. We currently use service_enter_signal(s, SERVICE_FINAL_SIGTERM, f), where f != SERVICE_SUCCESS in case of failure, but this does not cause a pass through STOP_POST.

• service_enter_running (since 3d474ef we fail services with RemainAfterExit=yes when their main process terminates unsuccessfully)
• service_sigchld_event
• service_notify_cgroup_empty_event
• service_dispatch_timer (Warning: we call service_enter_signal(s, SERVICE_FINAL_SIGTERM, SERVICE_FAILURE_TIMEOUT) when stop-post times out, but not only in that case)
• service_enter_stop_post itself
• service_enter_start
• service_run_next_control

Do we mean SERVICE_STOP_SIGTERM in some of these cases, or do we need SERVICE_FAIL_SIGTERM that acts like SERVICE_FINAL_SIGTERM, but passes through service_enter_stop_post?

As for the setting of $EXIT_STATUS and $EXIT_CODE, the documentation glosses over a corner case: it is possible that there has been no main process, so there is no meaningful value for these variables. We could make this more explicit by adding a new value for EXIT_STATUS, namely "n.a.". We could also just document that it can happen, and is meaningful, that these variables are not set.

Reminder:

• Add the row for "protocol" errors when this is resolved (either "exited"/"0", or "n.a."/not set)

[evverx]

@joukewitteveen , oh, that's a great summary. Thanks!

I'll try to reread #3818

I'm not sure I remember what is the purpose of the $EXIT_CODE, $EXIT_STATUS and $SERVICE_RESULT

[joukewitteveen]

And of course #1254, where @poettering implies that we might indeed want SERVICE_STOP_SIGTERM instead of SERVICE_FINAL_SIGTERM.

I am not entirely sure why we use service_enter_signal from service_notify_cgroup_empty_event, since there shouldn't be anything to kill anyway in that situation.