mjhjmtu

Systemd, when processing a .service file, is able to execute scripts in the ExecStartPre and ExecStartPost clauses. These scripts can return values to systemd.

In the documentation for systemd, it indicates that a return value of anything but 0 is considered a failure, and unless that clause was prefixed with '-' indicates that this attempt to launch the service will be aborted.

An aborted launch attempt is no big deal, because systemd will simply reattempt to launch the service, unless the service is marked as simple (I think).

In a script that I've inherited, the author indicates that a return value of 111 informs systemd that not only should the launch be aborted, but that no further launches are to be attempted. Elsewhere the script conditionally returns 10, or 11, in addition to the more typical 0. These return conditions seem integral to the functioning of the script.

I have been unable to find anything describing the interpretation of these return codes by systemd.

You have options for the main ExecStart command. I do not know, but suspect that the -Post and -Pre do not use those.

Accepting 10 and 11 as valid: SuccessExitStatus=

Viewing 111 as a total deal breaker: RestartPreventExitStatus=

Otherwise, you can always write a quick wrapper shell script to palliate to the lack of support in systemd.

I would do something like this:

#!/bin/sh

if [ -f /run/my-script-is-dead ]
then
 # to avoid very fast loop, sleep for a bit
 sleep 10
 exit 1
fi

# Run the script itself
/path/and/usual-command

# check result
RESULT=$?

if [ $RESULT -eq 10 ] || [ RESULT -eq 11 ]
then
 exit 0
fi

if [ $RESULT -eq 111 ]
then
 touch /run/my-script-is-dead
 exit 1
fi

exit $RESULT

But putting a file under /run, it will automatically disappear on each reboot. If you want something more permanent, then you'll have to create a file somewhere else (i.e. /var/cache/...)