More information is available in systemd.time(7). You can also specify a timezone at the end of the directive (use timedatectl list-timezones to list accepted values) In the example below, the service runs at 22:30 on weekdays and at 20:00 on weekends. To run a service at different times, OnCalendar may be specified more than once. If you want something to run every day at 4am, use: When using the DayOfWeek part, at least one weekday has to be specified. To run a service on the first Saturday of every month, use: In the below example the service is run the first four days of each month at 12:00 PM, but only if that day is a Monday or a Tuesday. When more specific dates and times are required, OnCalendar events uses the following format:ĭayOfWeek Year-Month-Day Hour:Minute:SecondĪn asterisk may be used to specify any value and commas may be used to list possible values. When activated, it triggers the service immediately if it missed the last start time (option Persistent=true), for example due to the system being powered off: The following examples schedule foo.service to be run with a corresponding timer called foo.timer.Ī timer which will start 15 minutes after boot and again every week while the system is running.Ī timer which starts once a week (at 12:00am on Monday). If deleted, they will be reconstructed on the next start of their timer.Ī service unit file can be scheduled with a timer out-of-the-box. These are zero length files which mark the last time each timer was run. If a timer gets out of sync, it may help to delete its stamp-* file in /var/lib/systemd/timers (or ~/.local/share/systemd/ in case of user timers).The status of a service started by a timer will likely be inactive unless it is currently being triggered.To list all timers (including inactive), use systemctl list-timers -all.Thu 19:37:03 CEST 11h left Wed 19:37:03 CEST 12h ago systemd-tmpfiles-clean.timer rviceįri 00:00:00 CEST 15h left Thu 00:00:13 CEST 8h ago logrotate.timer rvice $ systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES To use a timer unit enable and start it like any other unit (remember to add the. If necessary, it is possible to control a differently-named unit using the Unit= option in the timer's section. service does not require an section as it is the timer units that are enabled. To use it, add WantedBy=timers.target to the section of your timer and enable the timer unit. Note: systemd offers the target timers.target which sets up all timers that should be active after boot (see systemd.special(7) for details). The argument syntax for calendar events and time spans is defined in systemd.time(7). Common monotonic timers include OnBootSec and OnUnitActiveSec.įor a full explanation of timer options, see the systemd.timer(5). There are number of different monotonic timers but all have the form: On TypeSec=. They stop if the computer is temporarily suspended or shut down. Monotonic timers activate after a time span relative to a varying starting point.The option OnCalendar= is used to define them. wallclock timers) activate on a calendar event, the same way that cronjobs do. Timers are like other unit configuration files and are loaded from the same paths but include a section which defines when and how the timer activates. Timers are systemd unit files with a suffix of. Timers have built-in support for calendar time events, monotonic time events, and can be run asynchronously. Timers can be used as an alternative to cron (read #As a cron replacement). Timers are systemd unit files whose name ends in.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |