Allow custom `SuccessExitStatus=` to handle expected non-zero service exits

[gabelluardo]

What needs to get done

Snapcraft should allow specifying the SuccessExitStatus= directive in the systemd service definition for snaps. This would enable developers to mark certain non-zero exit codes as successful, preventing unwanted restart attempts or error logging in scenarios where the service termination is expected and not indicative of a fault.

The idea is to add a new field success-exit-status: [<success-codes>] in the snapcraft.yml file that will generate the SuccessExitStatus= in the systemd .conf file.

Example:

apps:
  daemon:
    ...
    restart-condition: on-failure
    restart-delay: 2s
    success-exit-status: [0, 1, SIGKILL]

Why it needs to get done

We need to implement a custom SuccessExitStatus= value for cases where the prompring-client daemon is intentionally disabled or stopped under expected conditions. Currently, when the daemon exits with a specific non-zero status code, systemd treats it as a failure and attempts to restart it, which is undesirable in these cases.

Allowing a custom SuccessExitStatus= setting will:

• Avoid unnecessary restarts of services under known, valid termination scenarios (like when the prompt is disabled)
• Reduce noise in system logs (see this discussion for more detail)
• Improve control over service lifecycle management within snaps

[mr-cal]

@olivercalder, can you confirm if this will require support from snapd to parse and handle success-exit-status?

[gabelluardo]

I can answer you on this as well, because I'm currently working on a PR to add support on the snapd side too. I hope it will be ready for review at EOD

[mr-cal]

@gabelluardo - nice, thanks!

[lengau]

Should exit-success-status be gated by checking if we have an appropriate assumes snapd... line?

[gabelluardo]

Sounds legit, can we assume this can be landed on 2.72 version of snapd?

[olivercalder]

Sounds legit, can we assume this can be landed on 2.72 version of snapd?

I don't think we can assume anything until it's landed. But we can certainly try to get it landed before 2.72. It's probably best to land the change in snapd first before marking an assumes snapd here.

[olivercalder]

https://github.com/canonical/snapd/pull/15826 didn't land in time for 2.73, but has since landed and will be included in 2.74. This is available now from the latest/edge channel of snapd, if you'd like to test.