Difference between revisions of "Talk:Systemd/Timers"

From ArchWiki
Jump to navigation Jump to search
(Adding section about timers not being able to start the one-shot service if "RemainAfterExit" option was used)
 
(22 intermediate revisions by 9 users not shown)
Line 1: Line 1:
== Counterproductive Suggestions ==
+
==Mailing output==
  
The suggestions on this page are counterproductive. By merging all units under a single target, you're intentionally creating a stampede when the timer goes off. One of the great features of timer units is that a combination of OnCalendar and AccuracySec can trivially mitigate the overlap that's associated with classic cron while still maintaining regularity. This is distinctly better than classic cron which would force a human to schedule the task jitter manually.
+
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).
 +
--[[User:Eigengrau|Eigengrau]] ([[User talk:Eigengrau|talk]]) 10:37, 14 May 2014 (UTC)
  
In addition, it isn't reasonable to queue these on basic.target as one wants a fully operational system before cron will run. Much like how cron daemons were treated like any other daemon and brought up in runlevel 3 under sysvinit, it makes much more sense to order timers on multi-user.target. [[User:Falconindy|Falconindy]] ([[User talk:Falconindy|talk]]) 23:38, 4 May 2014 (UTC)
+
:I just noticed that the [https://wiki.gentoo.org/wiki/Systemd#Emailing_failures Gentoo wiki] has an example using a {{ic|failure-email@.service}} which is started using {{ic|1=OnFailure=}}. This seems like the right way to do it, but I don't fully understand their code.
 +
:--[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 15:14, 6 October 2014 (UTC)
  
:Your remarks seem to make perfect sense and are corroborated by how the old {{ic|/etc/cron.*/}} files provided by packages in [base] group were converted to systemd.timer files (see https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026044.html and files present on one's system)).
+
::Hi, I rewrote this for inclusion in systemd-cron [https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/mail_on_failure mail_on_failure]. It nows checks for MAILTO=, like vixie-cron.
 +
::--[[User:A-detiste|A-detiste]] ([[User talk:A-detiste|talk]]) 08:02, 31 October 2014 (UTC)
  
:So to sum it up:
+
:::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 {{ic|1=OnFailure=}} approach suggested by the Gentoo wiki, described above.)
:*A different {{ic|/usr/lib/systemd/system/*.{timer,service}}} couple for every unit wanted should be created (or should {{ic|/etc/systemd/system/}} be used instead?);
+
:::--[[User:Liujed|Liujed]] ([[User talk:Liujed|talk]]) 20:12, 2 November 2014 (UTC)
:*Then a symbolic link to each custom {{ic|/usr/lib/systemd/system/*.timer}} file should be made in {{ic|/usr/lib/systemd/system/multi-user.target.wants/}};
 
  
:I've had a go at it for the {{Pkg|reflector}} service that I was running as a daily (ana)cron job, taking after the new {{ic|logrotate}} systemd.timer service converted by Thomas Bächler. Any comments appreciated.
+
::::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 [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766756 DebianBug]  and here [http://lists.freedesktop.org/archives/systemd-devel/2014-October/024268.html systemd-devel] .
===== Step one: create timer and service files for every different unit =====
+
::::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 [https://github.com/systemd-cron/systemd-cron/commit/66279cb72ef7d68c51ef5d3d7866497faedbe7fc underprivilieged user]
{{hc|/usr/lib/systemd/system/reflector.service|<nowiki>
+
::::So to there remains work to get "mail on output", here is some options:
[Unit]
+
::::* use some ExecStartPre= & ExecStartPost= magic that parse journalctl output with '--cursor' and save it somewhere
Description=Update pacman mirrorlist
+
::::* 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/")
 +
::::--[[User:A-detiste|A-detiste]] ([[User talk:A-detiste|talk]]) 11:31, 4 November 2014 (UTC)
  
[Service]
+
==AUR packages that provide missing cron feature==
Type=oneshot
 
ExecStart=/usr/bin/reflector --protocol http --latest 5 --sort rate --save /etc/pacman.d/mirrorlist
 
Nice=19
 
IOSchedulingClass=best-effort
 
IOSchedulingPriority=7
 
</nowiki>}}
 
  
{{Note|As for now this service file doesn't work. See my edit below for error log. {{ic|systemd}} gurus, your corrections are welcome.}}
+
Under [[Systemd/Timers#Using_a_crontab|Using a crontab]] it states that {{AUR|systemd-crontab-generator}} and {{AUR|systemd-cron}} provide an alternative to the missing {{ic|RANDOM_DELAY}} feature from [[cron]], both of the packages accomplish this using by simply translating the {{ic|RANDOM_DELAY}} (in minutes) environment variable to {{ic|AccuracySec}}(See the [https://github.com/systemd-cron/systemd-cron-next/blob/master/man/anacrontab.5.in systemd-crontab-generator] and [https://github.com/systemd-cron/systemd-cron/blob/master/src/man/anacrontab.5.in systemd-cron] man pages).
  
{{hc|/usr/lib/systemd/system/reflector.timer|<nowiki>
+
This goes against the advice in the note under [[Systemd/Timers#Caveats|Caveats]]:
[Unit]
+
:{{note|The {{ic|AccuracySec}} option is '''not''' useful for randomly staggering timers...}}
Description=Daily update of pacman mirrorlist
+
I'm not sure how this should be re-worded but it looks like (See [[#RANDOM_DELAY_cron_alternative_possible_in_systemd-229|RANDOM_DELAY cron alternative possible in systemd-229]]) the next version of systemd (229) will be getting a {{ic|RandomizedDelaySec}} feature so this could just be left until that changes. [[User:Alux|Alux]] ([[User talk:Alux|talk]]) 13:15, 29 December 2015 (UTC)
  
[Timer]
+
: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.
OnCalendar=daily
+
:[[User:Zeik|Zeik]] ([[User talk:Zeik|talk]]) 11:22, 15 March 2016 (UTC)
AccuracySec=12h
 
Persistent=true
 
</nowiki>}}
 
  
===== Step 2: Order timer on multi-user.target =====
+
::Both crontab packages have open issues to fix the functionality: [https://github.com/systemd-cron/systemd-cron-next/issues/35], [https://github.com/systemd-cron/systemd-cron/issues/45] [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:26, 12 April 2016 (UTC)
# ln -s /usr/lib/systemd/system/reflector.timer /usr/lib/systemd/system/multi-user.target.wants/reflector.timer
 
  
If the above is correct, this will lead to quite a massive overhaul of the wiki page... Waiting for other comments to proceed.
+
== Service File Example ==
  
'''Edit 2014-05-13''': the example service file I wrote for Reflector doesn't work. I get a failed status with systemctl:
+
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 {{ic|1=Type=oneshot}}?
{{hc|# systemctl status -l reflector|<nowiki>
 
● reflector.service - Update pacman mirrorlist
 
  Loaded: loaded (/usr/lib/systemd/system/reflector.service; static)
 
  Active: failed (Result: exit-code) since mer. 2014-05-14 00:00:10 CEST; 49min ago
 
  Process: 6149 ExecStart=/usr/bin/reflector --protocol http --latest 5 --sort rate --save /etc/pacman.d/mirrorlist (code=exited, status=1/FAILURE)
 
Main PID: 6149 (code=exited, status=1/FAILURE)
 
  
mai 14 00:00:10 arch-clevo reflector[6149]: error: failed to retrieve mirror data: (The read operation timed out)
+
[[User:Xordspar0|Xordspar0]] ([[User talk:Xordspar0|talk]]) 22:25, 23 March 2016 (UTC)
mai 14 00:00:10 arch-clevo systemd[1]: reflector.service: main process exited, code=exited, status=1/FAILURE
 
mai 14 00:00:10 arch-clevo systemd[1]: Failed to start Update pacman mirrorlist.
 
mai 14 00:00:10 arch-clevo systemd[1]: Unit reflector.service entered failed state.</nowiki>}}
 
  
Does anyone know how I should edit this file? I'll be trying different options taken from {{ic|systemd.service}} manpage, but if somebody is knowledgeable enough to spare us some time that's all right too...
+
: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. {{ic|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 {{ic|OnBootSec}} for example. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:33, 24 March 2016 (UTC)
-- [[User:Neitsab|Neitsab]] ([[User talk:Neitsab|talk]]) 11:44, 8 May 2014 (UTC), '''edited''' 23:25, 13 May 2014 (UTC)
 
  
:Well, I would say that it is a better idea to wait before editing this page. Falconindy, I remember some talk about AccuracySec not working properly on the [https://mailman.archlinux.org/pipermail/arch-general/2014-April/036019.html arch-general ML]. Has it been dealt with? - [[User:Genghizkhan91|Genghizkhan91]] ([[User talk:Genghizkhan91|talk]]) 05:41, 13 May 2014 (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.
 +
::[[User:Regid|Regid]] ([[User talk:Regid|talk]]) 19:50, 25 April 2019 (UTC)
  
Not sure if this is helpful, since it calls a script that does a bunch of things (including reflector) and e-mails me the output, but the following works for me. Except for a couple differences, the systemd service and timer files are largely the same as above. (I had to use "Type=forking", otherwise my MTA would complain about receiving a SIGTERM and would kill the message.) I can post the content of my {{ic|/usr/local/bin/pacman-sync}} too if you like, but it's probably not that interesting. After writing these files, I enabled and started {{ic|pacman-sync.timer}}.
+
== Timer [Install] Section ==
{{hc|/etc/systemd/system/pacman-sync.service|<nowiki>
 
[Unit]
 
Description=Update pacman mirrorlist, sync, and download packages
 
  
[Service]
+
The {{ic|[Install]}} section for timers is not mentioned at all in this article. According to {{ic|systemd.special(7)}}, timers should have {{ic|1=WantedBy=timers.target}}. Both of the timer examples have this line. Should this be mentioned in the "Timer units" section?
Type=forking
+
[[User:Xordspar0|Xordspar0]] ([[User talk:Xordspar0|talk]]) 01:24, 12 April 2016 (UTC)
ExecStart=/usr/local/bin/mail-output root "%H: pacman-sync" /usr/local/bin/pacman-sync
 
Nice=19
 
IOSchedulingClass=best-effort
 
IOSchedulingPriority=7</nowiki>}}
 
  
{{hc|/etc/systemd/system/pacman-sync.timer|<nowiki>
+
:Yes. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 13:23, 12 April 2016 (UTC)
[Unit]
 
Description=Daily update of pacman mirrorlist, sync, and download of packages
 
  
[Timer]
+
::Thread opener wrote {{man|7|systemd.specials}} '''mandates (should)''' timers to have {{ic|[Install]}} {{ic|1=WantedBy=timers.target}}. As of this writing,
OnCalendar=daily
+
::# {{man|7|systemd.specials}} recommends, as opposed to mandates, that. Similarly, {{man|5|systemd.unit}} only suggests (may).
AccuracySec=12h
+
::# 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 {{man|7|systemd.specials}} talks about.
Persistent=true
+
::[[User:Regid|Regid]] ([[User talk:Regid|talk]]) 21:19, 25 April 2019 (UTC)
  
[Install]
+
== oneshot service and OnUnitActiveSec vs. OnUnitInactiveSec ==
WantedBy=multi-user.target</nowiki>}}
 
  
{{hc|/usr/local/bin/mail-output|<nowiki>
+
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.
#!/usr/bin/bash
 
  
RECIPIENT="$1" ; shift
+
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)
SUBJECT="$1" ; shift
 
CMD="$@"
 
  
# Mails the output of the given CMD to the given RECIPIENT with the given SUBJECT.
+
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.  
# No mail is sent if no output is produced.
 
"$@" 2>&1 | /usr/bin/mail -E -s "${SUBJECT}" "${RECIPIENT}"</nowiki>}}
 
 
 
-- [[User:Liujed|Liujed]] ([[User talk:Liujed|talk]]) 05:43, 23 May 2014 (UTC)
 
 
 
 
 
Finally found how to make sure it works [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 18:47, 11 June 2014 (UTC)
 
 
 
This unit makes sure that at the time it is fired up the host is available. If it isn't, it will keep trying.
 
{{hc|/etc/systemd/system/reachable-retry@.service|<nowiki>
 
[Unit]
 
Description=Test if %i is reachable
 
# Customize to your own needs, with network.target or whatever works less worse with you
 
After=systemd-networkd-wait-online.service
 
 
   
 
   
[Service]
+
https://github.com/systemd/systemd/issues/6680
Type=forking
 
ExecStart=/usr/bin/ping -c1 %i
 
Restart=on-failure
 
 
 
[Install]
 
WantedBy=multi-user.target</nowiki>}}
 
 
 
{{hc|/etc/systemd/system/timer-daily.target.wants/reflector.service|<nowiki>
 
[Unit]
 
Description=Update mirorlist
 
# Fire up the tester
 
Requires=reachable-retry@www.archlinux.org.service
 
# Wait for it to return SUCCESS
 
After=reachable-retry@www.archlinux.org.service
 
 
 
[Service]
 
# Copied from wiki
 
Nice=19
 
IOSchedulingClass=2
 
IOSchedulingPriority=7
 
Type=oneshot
 
# Customize to your own needs
 
ExecStart=/usr/bin/reflector -i (fr|nl|be). -f 5 --save /etc/pacman.d/mirrorlist</nowiki>}}
 
And voilà [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 18:47, 11 June 2014 (UTC)
 
 
 
=== Edited ===
 
 
 
I think the arguments against unified timers makes sense, so I went ahead and removed that section. I then combined info from other sections to form a more complete example. This left the service examples orphaned (since they all relied on the unified timers) so I moved them (when possible) to their appropriate pages.
 
[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 21:01, 28 July 2014 (UTC)
 
 
 
=== A bit like unified timer ===
 
 
 
Solution that solves everything I think (though not perfect as it only works on single services):
 
{{hc|/etc/systemd/system/timer-daily@.timer|<nowiki>[Unit]
 
Description=Daily Timer for the %i service
 
 
 
[Timer]
 
OnCalendar=daily
 
Persistent=true
 
Unit=%i.service
 
 
 
[Install]
 
WantedBy=multi-user.target</nowiki>}}
 
and then
 
systemctl enable timer-daily@myservice.timer
 
And Voilà!
 
[[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 21:59, 1 September 2014 (UTC)
 
 
 
That is definitely nicer than the old unified timer example! However it still has the problem of all services using this timer starting simultaneously, which I think was the main complaint originally. Though based on the discussion about AccuracySec being random per-host (and thus useless for timer jitter), we still have no better solution than just per-service timers with manually staggered triggers.
 
[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 22:47, 1 September 2014 (UTC)
 
 
 
Workaround for the particular issue "they all fire up at the same time":
 
{{hc|/etc/systemd/system/timer-daily@myservice.timer.d/time.conf|<nowiki>[Timer]
 
# man 7 systemd.time
 
# adjust for each service that should not run with all others
 
OnCalendar=*-*-* 1:30:0
 
# Disable Persistence if you don't want the timer to "catch up"
 
#Persistent=false</nowiki>}}
 
This way, the last systemctl command still works and we can set a different time in the override configuration. Still a bit of a heavy solution, though [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 07:38, 2 September 2014 (UTC)
 
 
 
:The above discussion shows how the current content of the article was developed, but it might be better to start a fresh item in case related questions arise again. We could close it and, once removed, still refer to it via the history if needed.
 
:Or is there demand for keeping this discussion open? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:02, 9 January 2015 (UTC)
 
 
 
==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).
 
--[[User:Eigengrau|Eigengrau]] ([[User talk:Eigengrau|talk]]) 10:37, 14 May 2014 (UTC)
 
 
 
I just noticed that the [https://wiki.gentoo.org/wiki/Systemd#Emailing_failures Gentoo wiki] has an example using a {{ic|failure-email@.service}} which is started using {{ic|1=OnFailure=}}. This seems like the right way to do it, but I don't fully understand their code.
 
--[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 15:14, 6 October 2014 (UTC)
 
 
 
Hi, I rewrote this for inclusion in systemd-cron [https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/mail_on_failure mail_on_failure]
 
It nows checks for MAILTO=, like vixie-cron.
 
--[[User:A-detiste|A-detiste]] ([[User talk: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 {{ic|1=OnFailure=}} approach suggested by the Gentoo wiki, described above.) --[[User:Liujed|Liujed]] ([[User talk: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 [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766756 DebianBug]  and here [http://lists.freedesktop.org/archives/systemd-devel/2014-October/024268.html 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 [https://github.com/systemd-cron/systemd-cron/commit/66279cb72ef7d68c51ef5d3d7866497faedbe7fc 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/")
 
::--[[User:A-detiste|A-detiste]] ([[User talk:A-detiste|talk]]) 11:31, 4 November 2014 (UTC)
 
 
 
== <s>Parallelization section is confusing</s> ==
 
 
 
The section on parallelization is not at all about parallelization. Systemd timers are already parallel: you can schedule them at any time regardless of other timers. The section is really about staggering timers to prevent large numbers of timers from elapsing at the ''exact same time''. More importantly, the section doesn't convey a clear message. The first paragraph mentions that there is no good way to stagger timers using {{ic|AccuracySec}}, then the second paragraph seems to argue ''against'' staggering timers. So which is it?
 
 
 
Secondly, the whole discussion about {{ic|AccuracySec}} is not clearly relevant. It is only mentioned as it ''seems'' like it might be a solution even though it isn't. So then why do we need to argue for the design of it and mention energy consumption? Is it useful or is it not? How exactly does {{ic|AccuracySec}} help with power consumption? Why should we care?
 
[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 15:01, 6 October 2014 (UTC)
 
 
 
:Hi, your questions are triggered by my edit [https://wiki.archlinux.org/index.php?title=Systemd/cron_functionality&diff=338918&oldid=338863] in the section [[Systemd/cron functionality#Parallelization]] yesterday? Let me add: I looked into the section, because we have a [[ArchWiki:Reports|report]] on a related edit [https://wiki.archlinux.org/index.php?title=Systemd/cron_functionality&diff=330903&oldid=330391] and I was working on how we can handle it. Let's see to fix the topic so the report is dealt with as well. Thanks.
 
:You write above that the option "seems like it might be a solution even though it isn't." - can you explain to me why? You do not see it useful at all related to timing events or only not for 'parallelization'? (yes, I have read above talk items, but I'm still puzzling what you mean; we can come back to your above questions right after that). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:24, 7 October 2014 (UTC)
 
 
 
::Let's start from scratch to ensure that we're on the same page. Suppose you have a bunch of timers all set to {{ic|1=OnCalendar=weekly}}. Now that really means "Monday at midnight", so all of your timers will activate their services at the exact same time. In cron talk, this "stampede" of jobs is generally frowned upon and there are several mechanisms that have been created to avoid it (e.g. the {{ic|RANDOM_DELAY}} variable). The original motivation of the "parallelization" section was to point out that systemd timers do not have an equivalent mechanism.
 
::{{ic|AccuracySec}} is often mentioned as such a mechanism, but {{ic|systemd.timer(5)}} states "the expiry time... is synchronized between all local timer units". So it sounds like if you were to add {{ic|1=AccuracySec=1h}} to all of your {{ic|1=OnCalendar=weekly}} timers, you would ''still'' get a stampede - just not necessarily right at midnight. Perhaps {{ic|AccuracySec}} does serve some useful purpose, but if it has no use for randomly staggering timers to prevent stampedes then that discussion does not belong in the parallelization section.
 
::If {{ic|AccuracySec}} ''does'' help with stampedes, then I really need someone to explain what the hell "synchronized between all local timer units" means if the timers are not activated at the same time. Alternatively, if such stampedes are not a problem with ''systemd'', the article should explain why - as it is a rather common viewpoint.
 
::--[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 13:48, 7 October 2014 (UTC)
 
 
 
:::Ok, thanks! You most definetely have more practical experience with it, but let me contrast your summary with my understanding of it: With default configuration the example in [[Systemd/cron_functionality#Realtime timer]] with {{ic|1=OnCalendar=Wed, 23:15}} would kick off accordingly. (with an accuracy of 1 minute == default configuration). A 'stampede' in the historic cron sense would arguably only happen if you force all timers to realtime ("exact same time") on calender with something like {{ic|1=AccuracySec=1usec}}, which we do not do i.e. default applies.
 
:::Now, let's say you add another timer event with the same {{ic|1=OnCalendar=Wed, 23:15}}, it would be started within the same minute but not the same {{ic|usec}} as the first one (anti-stampede ala cron's randomdelay). I might be wrong on something, but I believe that is also what falconindy referred to in his first paragraph, first talk item.
 
:::''Of course'' if both those timed events are intensive on the same resource (e.g. bandwith, cpu, disk i/o), one has to control that (Nice, IOSchedulingClass, ...) or even spread them out more - but that is specific to the timed tasks. However, if resource restraints are not the primary concern, one can set something like {{ic|1=OnCalendar=daily, 23:15}} and even expand to {{ic|1=AccuracySec=23h}} (or 24h, not sure now). This should lead to all timers scheduled daily at any time be staggered close to each other. Taking this example further (I have not tried this): Let's say the system is a small homeserver and auto-suspended. If you additionally use {{ic|WakeSystem}} in the timers, the {{ic|1=AccuracySec=23h}} should make it wake up only once daily to excute timed events (energy consumption).
 
:::Are we getting closer? Am I wrong somewhere?
 
:::Apart from coming to the same understanding, I think you are clearly right that that the section needs more verbose to explain and "parallelization" is the wrong section title for it.
 
:::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:30, 7 October 2014 (UTC)
 
  
::::I think that, "it would be started within the same minute but not the same {{ic|usec}} as the first one" is the point of disagreement. I read "synchronized between local timers" as meaning that timers with the same {{ic|On...}} option and the same {{ic|AccuracySec}} would activate at practically the exact same time. I have tested this by creating three services that all run {{ic|date +%s.%N}} to display the current time in seconds and nanoseconds and three timers all with {{ic|1=OnCalendar=*-*-* *:*:00}} (every minute) and {{ic|1=AccuracySec=30s}}. Here are the results:
+
So I wonder, if OnUnitInactiveSec would be the correct parameter to start counting relaunch after the service has finished.
{{bc|Oct 07 16:48:22 h5g-max date[5214]: 1412714902.218033473
 
Oct 07 16:48:22 h5g-max date[5215]: 1412714902.218698707
 
Oct 07 16:48:22 h5g-max date[5217]: 1412714902.219415650
 
  
Oct 07 16:49:15 h5g-max date[5224]: 1412714955.163915339
+
{{unsigned|14:52, 15 October 2019‎|Juhanima}}
Oct 07 16:49:15 h5g-max date[5225]: 1412714955.165712079
 
Oct 07 16:49:15 h5g-max date[5226]: 1412714955.167225757
 
  
Oct 07 16:50:22 h5g-max date[5340]: 1412715022.189751381
 
Oct 07 16:50:22 h5g-max date[5341]: 1412715022.192302896
 
Oct 07 16:50:22 h5g-max date[5342]: 1412715022.193473285}}
 
::::So even though all three services do start at a random point between 00 and 30, they are all started within milliseconds of each other (sometimes even less)! This is certainly not the same sort of behavior as cron's {{ic|RANDOM_DELAY}}. Furthermore, if we change the timers to {{ic|1=AccuracySec=1us}} (the most accurate, according to the man page), we get the exact same millisecond-separation between services:
 
{{bc|Oct 07 16:59:00 h5g-max date[5458]: 1412715540.037773807
 
Oct 07 16:59:00 h5g-max date[5460]: 1412715540.039115540
 
Oct 07 16:59:00 h5g-max date[5459]: 1412715540.038436570
 
  
Oct 07 17:00:00 h5g-max date[5464]: 1412715600.006456259
+
== Oneshot service and RemainAfterExit ==
Oct 07 17:00:00 h5g-max date[5465]: 1412715600.008399768
 
Oct 07 17:00:00 h5g-max date[5466]: 1412715600.013211128
 
  
Oct 07 17:01:00 h5g-max date[5473]: 1412715660.008787964
+
I noticed the timer would not attempt to start the `oneshot` service again if `RemainAfterExit` was used.
Oct 07 17:01:00 h5g-max date[5474]: 1412715660.009727101
 
Oct 07 17:01:00 h5g-max date[5475]: 1412715660.011859585}}
 
::::From this I conclude that {{ic|AccuracySec}} is ''not'' useful for staggering multiple services with the same start time. In fact, my new theory is that its purpose is exactly the opposite - to create stampedes! That makes sense with your example of waking a machine once per day. For example, if we have a timer with {{ic|1=OnCalendar=*-*-* 10:00:00}}, {{ic|1=AccuracySec=4h}} and another with {{ic|1=OnCalendar=*-*-* 12:00:00}}, {{ic|1=AccuracySec=1h}}, systemd can choose to activate both timers at the same time and thus only wake the system once. I have no evidence that it does this, but if that is indeed the behavior it might be worth mentioning in some other section of the article.
 
::::--[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 21:26, 7 October 2014 (UTC)
 
  
:::::That's an interesting test and results! So my above assumption about setting {{ic|1=AccuracySec=1us}} was clearly wrong. I wrote that because I [https://bugzilla.redhat.com/show_bug.cgi?id=1074951#c3 read] that the option behind AccuracySec, {{ic|TimerSlackNSec}} defaults to 50us. In our config I don't see that value though, not sure what that means. The grouping/coalescing if the events we talk about is done in sd-event.h [http://lwn.net/Articles/587373/], maybe it is defined there. I'm still not fully convinced we would call it a stampede. It would be interesting if something changes with the date timers, if {{ic|TimerSlackNSec}} is set to a greater slack (e.g. 5ms) to test.
+
This combination was resulting in timer being stuck in `Left == N/A` state after first trigger:
:::::Related as a reference I saw the following bug: [https://bugs.freedesktop.org/show_bug.cgi?id=82084]
 
:::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:25, 8 October 2014 (UTC)
 
  
::::::Thanks for the bug links!
+
    cat >/etc/systemd/system/my_script.timer<<EOF
::::::I just did another test, this time with hourly timers starting at 00, 20, and 30 minutes but with {{ic|AccuracySec}} 40m, 20m, 10m, respectively. I had hoped to see some kind of coalescing (since a single start time between 30 and 40 minutes would satisfy every timer). Instead the timers started at 12:00:17, 12:20:17, and 12:30:17. So again it looks like they all got the same {{ic|AccuracySec}}. This also seems to backup Lennart's comment that "it will only really place the wakeup within 1min of range at max. If you set larger values it won't care". I'm still utterly confused about the purpose of {{ic|AccuracySec}} but seeing as it clearly has nothing to do with staggering start times between timers, I will update the article accordingly.
+
    [Unit]
::::::--[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 16:37, 8 October 2014 (UTC)
+
    Description=schedule regular restarts of my script
 +
   
 +
    [Timer]
 +
    OnCalendar=*-*-* 03:00:00
 +
   
 +
    [Install]
 +
    WantedBy=multi-user.target
 +
    EOF
  
:::::::I also saw Lennart's comment about the minute, but did not take that for current because the systemd.conf option he proposes for it at the same time was already added in 216. Nonetheless, your second test above sure indicates it does not work as intended/described. Thanks! I'll refrain from adding in something about a 'coalescing wakeup to reduce energy consumption' again until I have witnessed it works ^^  --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:35, 8 October 2014 (UTC)
+
    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
  
:::::::I believe this talk item was implemented by reworking the "Parallezation" subsection to [[Systemd/Timers#As_a_cron_replacement]]. As such I propose to close this item and open a fresh one which states a reference to it. The fresh item because I believe the test results by Silverhammermba would be a very useful base to reconsider the item once there are relevant changes to systemd and its handling of the {{ic|AccuracySec}} parameter. I don't use timers enough myself to follow it up right away again.  
+
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.
:::::::Objections against closing this and using a reference instead? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 9 January 2015 (UTC)
 
  
:::::::Simpler than creating a reference item here, I just added [https://wiki.archlinux.org/index.php?title=Systemd%2FTimers&diff=356407&oldid=356030]; it fits there well, complementing the bug. Closing. I will update the link once this is removed. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:15, 12 January 2015 (UTC)
+
[[User:Gregosky|Gregosky]] ([[User talk:Gregosky|talk]]) 06:05, 26 March 2020 (UTC)

Latest revision as of 06:05, 26 March 2020

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-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, 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,
  1. systemd.specials(7) recommends, as opposed to mandates, that. Similarly, systemd.unit(5) only suggests (may).
  2. 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)

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)