Talk:Systemd/Timers

Mailing output

Are there any built-in facilities for e-mailing the output of timed services? It doesn’t look as if there are. Maybe the wiki could outline a good practice for achieving that effect. A simple workaround would be having the service pipe output into sendmail, but maybe there’s a more elegant way (e.g., maintaining this would be cumbersome for many services). --Eigengrau (talk) 10:37, 14 May 2014 (UTC)

I just noticed that the Gentoo wiki has an example using a failure-email@.service which is started using OnFailure=. This seems like the right way to do it, but I don't fully understand their code.

--Silverhammermba (talk) 15:14, 6 October 2014 (UTC)

Hi, I rewrote this for inclusion in systemd-cron mail_on_failure. It nows checks for MAILTO=, like vixie-cron.

--A-detiste (talk) 08:02, 31 October 2014 (UTC)

mail_on_failure's behaviour doesn't match vixie-cron's. Whereas mail_on_failure only sends mail when a job has failed, vixie-cron will send mail containing the job's output regardless of the job's exit status. (Same probably goes for the OnFailure= approach suggested by the Gentoo wiki, described above.)

--Liujed (talk) 20:12, 2 November 2014 (UTC)

Indeed, the taste of users varies on this; OnFailure= was absolutely needed and easy to implement "mail on output" is not so straightforward. I've already discussed this elsewhere DebianBug and here systemd-devel .

Putting in a wrapper script between ExecStart= and the actual script is an added point of failure; using OnFailure is more robust. I even have this mailer run with an underprivilieged user

So to there remains work to get "mail on output", here is some options:

use some ExecStartPre= & ExecStartPost= magic that parse journalctl output with '--cursor' and save it somewhere
read $MAINPID in ExecStartPost= and do something with it
use a wrapper ("ExecStart=/usr/lib/mail_on_output /usr/bin/run-parts /etc/cron.daily/")

--A-detiste (talk) 11:31, 4 November 2014 (UTC)

AUR packages that provide missing cron feature

Under Using a crontab it states that systemd-crontab-generator^AUR and systemd-cron^AUR provide an alternative to the missing RANDOM_DELAY feature from cron, both of the packages accomplish this using by simply translating the RANDOM_DELAY (in minutes) environment variable to AccuracySec(See the systemd-crontab-generator and systemd-cron man pages).

This goes against the advice in the note under Caveats:

Note: The AccuracySec option is not useful for randomly staggering timers...

I'm not sure how this should be re-worded but it looks like (See RANDOM_DELAY cron alternative possible in systemd-229) the next version of systemd (229) will be getting a RandomizedDelaySec feature so this could just be left until that changes. Alux (talk) 13:15, 29 December 2015 (UTC)

I have removed the now outdated info on missing random delay, but it might be a good idea to keep this discussion around until a fix is implemented in systemd-cron.

Zeik (talk) 11:22, 15 March 2016 (UTC)

Both crontab packages have open issues to fix the functionality: [1], [2] Silverhammermba (talk) 19:26, 12 April 2016 (UTC)

Service File Example

It would be nice to add an example service unit file alongside the timer unit example. While there are examples of service units in the main systemd article, the service unit that accompanies a timer might be different. For example, wouldn't it usually be a good idea for a service controlled by a timer to have Type=oneshot?

Xordspar0 (talk) 22:25, 23 March 2016 (UTC)

If your concern is that a timer might try to start a service while it is already running, the service type won't help with that. oneshot only prevents dependent units from starting before the service exits, but timers are not dependent. Also consider a service that runs forever: such a service can still be reasonably started by a timer, using OnBootSec for example. Silverhammermba (talk) 19:33, 24 March 2016 (UTC)

One might look at system timers for service file examples.

% systemctl list-timers

pick some service file, say shadow.service, and

% systemctl cat shadow.service

The .timer file can also be seen in a similar manner. Since shadow is part of base group, it will be installed on virtually any system.

Regid (talk) 19:50, 25 April 2019 (UTC)

Timer [Install] Section

The [Install] section for timers is not mentioned at all in this article. According to systemd.special(7), timers should have WantedBy=timers.target. Both of the timer examples have this line. Should this be mentioned in the "Timer units" section? Xordspar0 (talk) 01:24, 12 April 2016 (UTC)

Yes. Silverhammermba (talk) 13:23, 12 April 2016 (UTC)

Thread opener wrote systemd.specials(7) mandates (should) timers to have [Install] WantedBy=timers.target. As of this writing,

systemd.specials(7) recommends, as opposed to mandates, that. Similarly, systemd.unit(5) only suggests (may).
shadow.timer doesn't have it. So does systemd-tmpfiles-clean.timer, which is part of systemd. Though it might not considered an application, which systemd.specials(7) talks about.

Regid (talk) 21:19, 25 April 2019 (UTC)

I didn't mean to imply that it was mandatory. I'll add a note that if you want your timer to be active at boot, the way to do that is to add WantedBy=timers.target. Xordspar0 (talk) 18:09, 8 August 2020 (UTC)

oneshot service and OnUnitActiveSec vs. OnUnitInactiveSec

This page contains an example of configuring a type=oneshot service to run with regular intervals with a monotonic timer. The relaunch timeout is defined by OnUnitActiveSec in the [Timer]-section.

I just started to encounter mysterious errors, with the timer running once in boot and then going in inactive state, after upgrading to a newer version (it was Debian 10, but I suspect the same problem applies to Arch Linux)

In this discussion, Lennart Poettering says that the combination of type=oneshot and OnUnitActiveSec=xxx does not make sense. If the service finishes before it has been active (running?) the given time, the relaunch may fail.

https://github.com/systemd/systemd/issues/6680

So I wonder, if OnUnitInactiveSec would be the correct parameter to start counting relaunch after the service has finished.

—This unsigned comment is by Juhanima (talk) 14:52, 15 October 2019‎. Please sign your posts with ~~~~!

Oneshot service and RemainAfterExit

I noticed the timer would not attempt to start the `oneshot` service again if `RemainAfterExit` was used.

This combination was resulting in timer being stuck in `Left == N/A` state after first trigger:

   cat >/etc/systemd/system/my_script.timer<<EOF
   [Unit]
   Description=schedule regular restarts of my script
   
   [Timer]
   OnCalendar=*-*-* 03:00:00
   
   [Install]
   WantedBy=multi-user.target
   EOF

   cat >/etc/systemd/system/my_script.service<<EOF
   [Unit]
   Description=my script
   After=syslog.target network-online.target
   
   [Service]
   Type=oneshot
   RemainAfterExit=yes
   
   ExecStart=/usr/bin/bash /path/to/my_script.sh
   
   ProtectSystem=true
   
   RestartSec=60s
   TimeoutSec=120s
   
   [Install]
   WantedBy=multi-user.target
   EOF

As soon as I removed `RemainAfterExit` timer seems to be working as expected. I might be incorrect to say this but I think this is the feature of systemd - it will not attempt to start the service which is in "active" state.

Gregosky (talk) 06:05, 26 March 2020 (UTC)