2

How can I get the following timer to start automatically? Right now the timer only works if I do systemctl start while-test.timer. Otherwise, eventhough I enabled the timer, it does not start automatically. Even after doing systemctl daemon-reload or rebooting.

while-test .service
-------------------
[Unit]
Description=While loop test script

[Service]
Type=simple
ExecStart=/home/user/bash/while-test.sh

[Install]
WantedBy=default.target

and

while-test .timer
----------------
[Unit]
Description=While loop test script timer

[Timer]
OnCalendar=Mon *-*-* 10:52:00
Unit=while-test.service

[Install]
WantedBy=default.service
2
  • What is the output of systemctl --all list-timers? Are the timer and unit user specific or system wide?
    – Munir
    Aug 31, 2017 at 17:44
  • Based on a previous question, can you look at the journal? You should see a few log lines under sudo systemctl status while-test.timer (the sudo may be required to get the logs), or you can use journalctl -b -u while-test.timer
    – sourcejedi
    Jul 27, 2018 at 18:24

2 Answers 2

3
systemctl enable while-test.service
systemctl enable while-test.timer

You may need to run these with sudo. This enables the service and timer at boot. Verify that it is enabled with:

systemctl list-timers

This will show status information like next run time, last run time, last passed run, and the service it activates.

3

Although it may not be the cause for the OP's issue, I had the exact same problem this week and in my case the cause was storing the true unit files on a drive partition that was mounted at boot after systemd loaded the timers (pointing to them with symlinks).

In fact, inspecting my systemd log (with journalctl -b) actually showed that the partition was being mounted ~0.01 seconds immediately after the timers were loaded. Rather it tried to load the timers but complained (in the log) that the files did not exist.

So just like in OP's case, I could manually start the timers fine after my system was up and running, but they wouldn't auto start at boot like they were supposed to.

For any variations of the same problem, I anticipate checking the log is likely to help the diagnosis.

I noticed the other answer on this page seems to infer the step of enabling the service along with the timer. There's a different stack exchange answer somewhere that regarded that step as superfluous or possibly confounding since it would presumably achieve the effect of auto starting the service like a normal daemon when the timer is supposed to be in control of it.

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.