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)
- 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 AUR and 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:
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)
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
- 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.
oneshotonly 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
OnBootSecfor example. Silverhammermba (talk) 19:33, 24 March 2016 (UTC)
Timer [Install] Section
[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)