53

I want to use systemd to run a command every 5 minutes. However, there is a risk that occasionally the task may take longer than 5 minutes to run. At that point, will systemd start a second instance of the command i.e. will I end up with 2 processes running?

Is it possible to tell systemd not to start a second process if the first hasn't completed? If not, what are some good workarounds?

Note: I hope the answer is "That's the default behavior. It just isn't documented." If this is the situation, can someone tell me how to file a bug against their docs?

Note: Cron has a similar issue which is discussed in https://unix.stackexchange.com/a/173928/11244. I'm looking for the systemd equivalent.

Improve this question

2 Answers 2

Reset to default
57

This is the default (and the only) behavior. It is not explicitly documented, but is implied by systemd's operation logic.

systemd.timer(5) reads:

For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses.

systemd(1), in turn, describes the concept of unit states and transitions between them:

Units may be "active" (meaning started, bound, plugged in, ..., depending on the unit type, see below), or "inactive" (meaning stopped, unbound, unplugged, ...), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called "activating", "deactivating").

This means that the triggering of a timer leads to "activation" of the matching unit, i. e. its transition to the "active" state.

If the matching unit is already "active" at the time of "activation" (for a service unit, this means "the main process is still running", unless the service unit has Type=oneshot and RemainAfterExit=true), it should be obvious that no action will be taken.

Improve this answer
11
  • 4
    @Gima an oneshot unit without any extra parameters is considered "activating" while its initial process is running, and becomes "inactive" when it exits. At this time, another trigger can activate that unit again. Commented Feb 22, 2017 at 2:22
  • 4
    @Gima ...however, an oneshot unit that has RemainAfterExit=true will remain "active" when its initial process exits, so subsequent triggers of a timer will be ignored unless an administrator explicitly deactivates (stops) that unit, or it is brought down by negative dependencies. Commented Feb 22, 2017 at 2:25
  • 7
    I keep getting rep as people invite this. I hope systemd doesn't clarify their docs. Commented Aug 11, 2017 at 12:57
  • 12
    This is now part of the systemd docs - Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running. There is no concept of spawning new service instances in this case. freedesktop.org/software/systemd/man/systemd.timer.html Commented Sep 13, 2017 at 16:29
  • 3
    @TomOnTime It's your reward for asking an obviously relevant question, so just enjoy as the rep keeps rolling in ;) Commented Aug 31, 2021 at 16:03
1

Just tested this and the unit seems to start immediately after the previous run ends, if the unit was scheduled to be started while the previous run still hadn't finished. I expected it to ignore that run and wait for the next timer invocation.

Improve this answer
1
  • This would be more appropriate as a comment rather than an answer. Unless you're going to add more details giving an actual solution, please consider copying the text into a comment on the appropriate section and retracting this answer. Commented Feb 20, 2024 at 3:57

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.