I have a backup.service called every hour by a backup.timer. Unfortunately the backup script running inside the container can complete successful but with warnings returning a non-zero exit code. So although everything may have worked, the container stops with a non-zero exitcode. So the unit enters failed state in fleet.

And in that case it seems, the timer won't start this unit again, altough I didn't find anything in the systemd docs saying that.

To make it clear: It's perfectly ok for me, to have the container stop with a non-zero exit code. But my timer then doesn't work.

I now could excapsulate that script into another which is then called als docker entrypoint. But I'll have to make sure that the output auf STDOUT and STDERR is somehow kept.

I also could run sudo systemctl reset-failed after the unit failed, but this seems to be a little hacky to me... (I tried that and in that case the timer ran the unit again. But it doesn't work as ExecStopPost-Task in the service file)

Is there any better way to make sure a that a unit

  • doesn't enter failed state though it's returning non-zero, or
  • reset it's state afterwards, or
  • tell the timer to run that unit altough its status is failed?

2 Answers 2


You could prefix your command with -, then systemd ignores the failure and won't put the unit into a failed state. So, instead of




See systemd man page for more.

  • 2
    Believe it or not. I have about 15 service-files with exactly the - in my ExecPre-Tasks. I just didn't realized this as the solution... You made my day. Thanks Apr 2, 2015 at 13:13

In case you want to ignore some return values, but still want some others to count to systemd as errors, you can specify them in the [Service] section of your .service file as a space-separated list to SuccessExitStatus, RestartPreventExitStatus, and RestartForceExitStatus. These also take signal names.

Reference: man 5 systemd.service

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .