I wanted a "more stupid" version of crontab: Run only on given times, don't catch up after suspension. I.e. when a service should have been triggered by crontab, but the machine was suspended, it was triggered right after resuming. That's what I didnt' want.

I solved this by writing a systemd.timer unit (instead of crontab) and accordingly a -sleep.service, which deactivated the timer unit, when the machine is going to suspend and reactivated the timer unit when the system resumed. Since my last update last weekend suddenly it behaved like crontab did: the timer unit started it's target, just when the timer unit got started, even though it wasn't a given time within the timer unit.

I checked the logs and the -sleep.service unit did it's job and deactivated the timer unit. (Also the timer unit is showing it's de- and reactivation.) However, as I said: I don't want the timer unit to "catch up". I want it ONLY triggering it's unit on given times, never else!

Thank you very much!

Regards Dom

# horcrux-sleep.service
Description=horcrux sleep hook                                   
ExecStart=/usr/bin/systemctl stop horcrux.timer                  
ExecStop=/usr/bin/systemctl start horcrux.timer                  
# horcrux.timer
Jun 27 06:51:15 citadel systemd[1]: Stopped Schedule for backup.
OnCalendar=Mon *-*-* 20..21:00:00                                                                                                 

OnCalendar=Tue..Thu *-*-* 17..21:00:00                           
OnCalendar=Fri *-*-* 17..23:00:00                                                                                                 

OnCalendar=Sat *-*-* *:00:00                                     
OnCalendar=Sun *-*-* 00..21:00:00                                
## Spätschicht                                                   
#OnCalendar=Mon..Wed,Fri *-*-* 7..11:00:00                       
## Frühschicht am Donnerstag                                     
#OnCalendar=Thu *-*-* 13..16:00:00                               
## Frühschicht täglich                                           
#OnCalendar=Mon..Fri *-*-* 7..11:00:00                           
## freie Tage                                                    
#OnCalendar=Mon..Fri 9..11,14..16,0..5:00:00                     
## Urlaub / Krankheit                                            
#OnCalendar=*-*-* *:00:00                                        

3 Answers 3


Maybe persistent interferes. https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Persistent=

Set Persistent=false

  • I changed to persistent=false, but every time the timer gets activated on resume (from suspend) the job is ran. → Problem persists.
    – DomX
    Commented Aug 27, 2023 at 16:06

You should not need to deactivate and reactivate while suspending/resuming when you use Persistent=true.
Because that's the whole idea of that directive, it stores info on disk for re-use.

So maybe the problem you are facing is due to the usage of your horcrux-sleep.service which should not be needed with systemd timers.

You should maybe check the value of RandomizedDelaySec= of the timer unit using systemctl show to see if it has a non zero value, in which case you could set it to 0.
Plus values of OnClockChange=, OnTimezoneChange= and RemainAfterElapse=

(See man systemd.timer for explanation of these directives)

  • Persistent=true is exactly what I NOT want. According to the manual it triggers a catch up for the unit if the timer would have triggered the unit while the timer was off. Please help me if I understood it wrong or if I don't get what's in your mind.
    – DomX
    Commented Sep 24, 2023 at 13:00
  • Then maybe you need to report at: github.com/systemd/systemd/issues Commented Sep 30, 2023 at 7:55
  • @DomX, did you read the description of the systemctl clean command? Maybe you need to use that when your machine returns from suspending... Commented Oct 23, 2023 at 10:47

After several tests, also Persistent=boolean didn't do the job. So far, I totally forgot about /etc/crontab and all times used crontab -e just to get the problems with anachron which leaded to the systemd configuration you see above and therefore this thread at all.

But adding the job to /etc/crontab does the job without anachron - without "catching up". 😁

All details for proper setup of /etc/crontab can be found within crontab manual.

The real issue: Difference between hardware clock and system clock.
Solution: Setting the Linux' system time to UTC via timedatectl set-local-rtc 0

In Detail:
The system is dual boot Linux and Windows. Once I set up this system it were Arch Linux and Windows 7. Now it is Manjaro Linux and Windows 10. While Arch was in charge, the hardware clock was set to UTC within Windows, so it fits Linux. But somehow, when I installed Manjaro, the Linux' system clock was set to local time (TZ).
So while Windows kept it's registry key and used UTC Linux started using TZ - and on every boot and resume the time jump caused by ntp triggered the service.
After some time testing I was able to verify. One still needs /etc/crontab to omit the catch up but also /etc/crontab is not enough, when time switches trigger. This also executes /etc/crontab/-entries.

You must log in to answer this question.

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