View source for Systemd (Русский)/Timers (Русский)

{{Lowercase title}}
[[Category:Русский]]
[[Category:Daemons and system services (Русский)]]
[[Category:Boot process (Русский)]]
[[en:Systemd/Timers]]
[[fr:Systemd/cron]]
[[ja:Systemd/タイマー]]
[[zh-CN:Systemd/Timers]]
{{Related articles start}}
{{Related|systemd (Русский)}}
{{Related|systemd/Пользователь}}
{{Related|systemd FAQ}}
{{Related|cron (Русский)}}
{{Related articles end}}
{{TranslationStatus (Русский)|Systemd/Timers|24 марта 2016|427528}}
Таймеры это файлы служб [[systemd (Русский)|systemd]] имя которых оканчивается на {{ic|.timer}} они контролируют файлы {{ic|.service}} или события. Таймеры могут использоваться как альтернатива [[cron (Русский)|cron]] (читайте [[#В качестве замены cron]]). Таймеры имеют встроенную поддержку временных календарных событий, монотонных временных событий, и могут быть запущены в асинхронном режиме.

== Юниты таймера ==

Таймеры ''systemd'' это файлы юнитов с суфиксом {{ic|.timer}}. Таймеры, как и другие файлы [[systemd (Русский)#Написание файлов юнитов|файлы настроек юнитов]] и загружаются по одному и тому же пути, но включают в себя секцию {{ic|[Timer]}}. Секция {{ic|[Timer]}} определяет, когда и как таймер активизируется. Таймеры определяются в качестве одного из двух типов:

* '''Монотонный таймер''' активируется после определенного промежутка времени по отношению к той или иной отправной точки. Есть несколько различных монотонных таймеров, но все они имеют вид: {{ic|1=On''Type''Sec=}}. {{ic|OnBootSec}} и {{ic|OnActiveSec}} являются общими монотонными таймерами.
* '''Таймер реального времени''' (также известный как таймер настенный часы) активируется на события календаря (как cronjobs). Для их определения используется опция {{ic|1=OnCalendar=}}.

Для полного объяснения опций таймера смотрите {{ic|systemd.timer(5)}} [[Страница справочного руководства|странице справочного руководства]]. Синтаксис аргументов для событий календаря и промежутка времени определяется на {{ic|systemd.time(7)}} [[Страница справочного руководства|странице справочного руководства]].

== Служба юнита ==

For each {{ic|.timer}} file, a matching {{ic|.service}} file exists (e.g. {{ic|foo.timer}} and {{ic|foo.service}}).  The {{ic|.timer}} file activates and controls the {{ic|.service}} file.  The {{ic|.service}} does not require an {{ic|[Install]}} section as it is the ''timer'' units that are enabled.  If necessary, it is possible to control a differently-named unit using the {{ic|1=Unit=}} option in the timer's {{ic|[Timer]}} section.

== Управление ==

To use a ''timer'' unit [[enable]] and [[start]] it like any other unit (remember to add the {{ic|.timer}} suffix).  To view all started timers, run:

{{hc|$ systemctl list-timers|
NEXT                          LEFT        LAST                          PASSED     UNIT                         ACTIVATES
Thu 2014-07-10 19:37:03 CEST  11h left    Wed 2014-07-09 19:37:03 CEST  12h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2014-07-11 00:00:00 CEST  15h left    Thu 2014-07-10 00:00:13 CEST  8h ago     logrotate.timer              logrotate.service
}}

{{Note (Русский)|
* To list all timers (including inactive), use {{ic|systemctl list-timers --all}}.
* The status of a service started by a timer will likely be inactive unless it is currently being triggered.
* If a timer gets out of sync, it may help to delete its {{ic|stamp-*}} file in {{ic|/var/lib/systemd/timers}}. These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.}}

== Пример ==

No changes to service unit files are needed to schedule them with a timer. The following example schedules {{ic|foo.service}} to be run with a corresponding timer called {{ic|foo.timer}}. 

=== Монотонный таймер ===

A timer which will start 15 minutes after boot and again every week while the system is running.

{{hc|/etc/systemd/system/foo.timer|<nowiki>
[Unit]
Description=Run foo weekly and on boot

[Timer]
OnBootSec=15min
OnUnitActiveSec=1w 

[Install]
WantedBy=timers.target
</nowiki>}}

=== Таймер в реальном времени ===

A timer which starts once a week (at 12:00am on Monday). It starts once immediately if it missed the last start time (option {{ic|1=Persistent=true}}), for example due to the system being powered off: 

{{hc|/etc/systemd/system/foo.timer|<nowiki>
[Unit]
Description=Run foo weekly

[Timer]
OnCalendar=weekly
Persistent=true     
 
[Install]
WantedBy=timers.target</nowiki>}}

{{Tip (Русский)|Special event expressions like {{ic|daily}} and {{ic|weekly}} refer to ''specific start times'' and thus any timers sharing such calendar events will start simultaneously. Timers sharing start events can cause poor system performance if the timers' services compete for system resources.  The {{ic|RandomizedDelaySec}} option avoids this problem by randomly staggering the start time of each timer. See {{ic|systemd.timer (5)}}.}}

== В качестве замены cron ==

Although [[cron]] is arguably the most well-known job scheduler, ''systemd'' timers can be an alternative.

=== Полезности ===

The main benefits of using timers come from each job having its own ''systemd'' service. Some of these benefits are:

* Jobs can be easily started independently of their timers. This simplifies debugging.
* Each job can be configured to run in a specific environment (see the {{ic|systemd.exec(5)}} [[man page]]).
* Jobs can be attached to [[cgroups]].
* Jobs can be set up to depend on other ''systemd'' units.
* Jobs are logged in the ''systemd'' journal for easy debugging.

=== Предостережения ===

Some things that are easy to do with cron are difficult to do with timer units alone.

* Complexity: to set up a timed job with ''systemd'' you create two files and run a couple {{ic|systemctl}} commands. Compare that to adding a single line to a crontab. 
* Emails: there is no built-in equivalent to cron's {{ic|MAILTO}} for sending emails on job failure. See the next section for an example of setting up an equivalent using {{ic|1=OnFailure=}}.

=== MAILTO ===

You can set up systemd to send an e-mail when a unit fails - much like Cron does with {{ic|MAILTO}}. First you need two files: an executable for sending the mail and a ''.service'' for starting the executable. For this example, the executable is just a shell script using {{ic|sendmail}}:

{{hc|/usr/local/bin/systemd-email|<nowiki>#!/bin/bash

/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <root@$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status --full "$2")
ERRMAIL</nowiki>}}

Whatever executable you use, it should probably take at least two arguments as this shell script does: the address to send to and the unit file to get the status of. The ''.service'' we create will pass these arguments:

{{hc|/etc/systemd/system/status-email-'''user1'''@.service|<nowiki>[Unit]
Description=status email for %I to </nowiki>'''user1'''<nowiki>

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email </nowiki>'''user1@mailhost'''<nowiki> %i
User=nobody
Group=systemd-journal
</nowiki>}}

First notice that the unit to send email about is an instance parameter, so this one service can be used to send email for many other units. However the recipient is hard-coded (since unit templates can only take a single parameter) so you will need to create multiple services if you want to send emails to different sets of recipients. At this point you should test the service to verify that you can receive the emails:

{{bc|# systemctl start status-email-user1@dbus.service}}

Then simply [[systemd#Editing provided units|edit]] the service you want emails for and add {{ic|1=OnFailure=status-email-user1@%n.service}} to the {{ic|[Unit]}} section. {{ic|%n}} passes the unit's name to the template.

{{note (Русский)|If you set up SSMTP security according to [[SSMTP#Security]] the user {{ic|nobody}} will not have access to {{ic|/etc/ssmtp/ssmtp.conf}}, and the {{ic|systemctl start status-email-user1@dbus.service}} command will fail. One solution is to use {{ic|root}} as the User in the {{ic|status-email-user1@.service}} module.}}

=== Использование crontab ===

Several of the caveats can be worked around by installing a package that parses a traditional crontab to configure the timers. {{AUR|systemd-cron-next}} and {{AUR|systemd-cron}} are two such packages. These can provide the missing {{ic|MAILTO}} feature.

If you like crontabs just because they provide a unified view of all scheduled jobs, {{ic|systemctl}} can provide this. See [[#Management]].

== Смотрите также ==

* [http://www.freedesktop.org/software/systemd/man/systemd.timer.html systemd.timer man page] на freedesktop.org (Англ.)
* [https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Fedora Project wiki page] on ''systemd'' calendar timers (Англ.)
* [https://wiki.gentoo.org/wiki/Systemd/ru#.D0.A1.D0.B5.D1.80.D0.B2.D0.B8.D1.81.D1.8B_.D1.82.D0.B0.D0.B9.D0.BC.D0.B5.D1.80.D0.BE.D0.B2 Раздел Gentoo wiki] Сервисы таймеров ''systemd''
* {{App|systemd-cron-next|утилита для создания таймеров/служб из файлов crontab и anacrontab |https://github.com/kstep/systemd-cron-next|{{Aur|systemd-cron-next}}}}
* {{App|systemd-cron|предоставляет юнитам systemd запускать скрипты cron; используя ''systemd-crontab-generator'' для конвертации crontab'ов|https://github.com/systemd-cron/systemd-cron|{{Aur|systemd-cron}}}}