2

I've been migrating my crontabs to systemd's timer units. They all look similar to this:

.timer file:

[Unit]
Description=timer that uses myjob.service

[Timer]
OnCalendar=*-*-* *:00:00
Unit=myjob.service

[Install]
WantedBy=timers.target

.service file:

[Unit]
Description=Script that runs myjob.sh

[Service]
ExecStart=/home/user/myjob.sh

My timers work but they also execute on system reboot. I would like my OnCalendar events to only run at the specified times, not whatever random time I reboot the PC. Any ideas?


UPDATE: I resolved this problem by converting my 'user' timers into root/system timers.

  1. I disabled all of my .service and .timer files, and moved them out of my home directory into /etc/systemd/system.

  2. I added the 'User=' section to each service file, so that my scripts were ran by the regular user and not as root.

Now my timers aren't being triggered on system startup and I was also getting problems with sporadic triggering when I logged in via ssh. This has also been solved now that they are under control of the root account but run my scripts are still run as the PID of regular user, which preserves my files' ownership attributes. Problem solved.

  • 1
    Please post your solution as an answer and accept it, that was the question is marked as solved and others can easily find the answer. – terdon May 18 '17 at 8:25
  • Since you never answered my comment, I posted your solution as an answer myself. If you decide you want to post it yourself and reap the reputation you deserve for it, let me know and I'll delete mine. – terdon May 22 '17 at 11:15
0

I resolved this problem by converting my 'user' timers into root/system timers.

  1. I disabled all of my .service and .timer files, and moved them out of my home directory into /etc/systemd/system.

  2. I added the 'User=' section to each service file, so that my scripts were ran by the regular user and not as root.

Now my timers aren't being triggered on system startup and I was also getting problems with sporadic triggering when I logged in via ssh. This has also been solved now that they are under control of the root account but run my scripts are still run as the PID of regular user, which preserves my files' ownership attributes. Problem solved.


The OP posted this as an edit to the question, so I reproduced it here.

2

I was also having the same problem and could not figure out why units would always run at startup regardless of the Persistent setting in the .timer file and it took me a while but I finally found the cause (pointed in the right direction by @alexander-tolkachev's comment).

The problem is that I have always included something like WantedBy=basic.target in the [Install] section of the .service file (because its part of the standard systemd service copy pasta). It turns out this actually causes the unit to be started whenever basic.target is (aka system boot).

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#WantedBy= https://www.freedesktop.org/software/systemd/man/systemd.special.html#basic.target

I suspect the OP inadvertently solved their issue by disabling the old .service (which you must do in order to remove the symlink created by WantedBy) and either omitting the [Install] section when they re-wrote it or never running systemctl enable.

TLDR; You do not want an [Install] section in a .service file that is triggered by a .timer file.

1

According documentation you should change your config to Persistent=false or remove Persistent at all, because it false by default.

  • Sorry, the example file I showed isn't representative of the real unit files I am having problems with. They have Persistent=false, so that isn't the problem. I will edit that line out. – bitofagoob May 9 '17 at 22:11
  • @bitofagoob try to remove Install section from .timer file. – Alexander Tolkachev May 10 '17 at 8:53
0

While investigating this problem on my own server, I discovered the following:

$ systemctl status man-db.timer
Apr 09 08:10:00 anemone systemd[1]: man-db.timer: Not using persistent file timestamp Mon 2018-04-16 19:40:02 EDT as it is in the future.
Apr 09 08:10:00 anemone systemd[1]: Started Daily man-db cache update.

Turns out the battery for the on-board RTC was dead, so the system was booting with a date in the past (probably taken from the filesystem). Confirmed by running

journalctl --boot

And seeing that the logs for the current boot have bad timestamps. Adding this in case anyone else's problem happens to match mine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.