CODEWITHSUNDEEP
timersystemd
MSalters
MSalters

Reputation: 179779

Systemd timer and conditional service interaction

I've got a conditional systemd service foo.service with condition ConditionDirectoryNotEmpty=/tmp/foo. It's a one-shot service to empty /tmp/foo.

This works correctly in isolation. If I start the service when /tmp/foo holds a file, the service runs and the file is removed. If not, the service is skipped. Either way, it runs in less than a second.

The problem arises when I try to start this service from an associated timer. The timer gets stuck in a broken state. systemctl list-timers shows that foo.timer has a NEXT entry in the past (!) and it fired one millisecond ago. Indeed, it appears to be continously firing. That's of course not the timer setting:

[Timer]
OnUnitActiveSec=
OnUnitActiveSec=60s
Persistent=true

60 seconds is a lot more than one minute. The empty OnUnitActiveSec= line is intentional; it should clear any existing timer period.

Why is the timer going berserk? Why is it firing so often, why is the next time to fire in the past? Most importantly, how do I run a service once a minute, but only if needed?

systemd version 215, on Debian 8 (Armbian 5.30)

Upvotes: 0

Views: 1621

Answers (1)

MSalters
MSalters

Reputation: 179779

There are apparently two parts to this question, each of which individually does not solve the problem.

The timer should have OnBootSec=... which defines the first time that the service runs after boot. The OnUnitActiveSec=60s only defines the interval between timer events, and does not tell you when the timer first fires.

Secondly, it appears that the service you're starting should be disabled. That doesn't make much sense to me either, but remember that a disabled service can still be started explicitly by systemctl start foo.service. It looks like an "enabled service" is merely one that is started automatically when its conditions are met (typically at boot). That's not how this one-shot service should behave; it should just run in response to the timer.

The start of foo.service can still be controlled by conditions in the service itself; this is still the case when the service start request is initiated by a timer.

Upvotes: 2

Related Questions