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 usingOnFailure=
. 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)
- 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
- 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-generatorAUR and systemd-cronAUR 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, usingOnBootSec
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)
- One might look at system timers for service file examples.
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)
- Thread opener wrote systemd.specials(7) mandates (should) timers to have
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.