X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fsystemd.timer.xml;h=317fbf1f2fa2f9dce09cdcafffb84240ff7581d6;hp=55b458557f357634ae7f27591cbd8cddf7001e30;hb=798d3a524ea57aaf40cb53858aaa45ec702f012d;hpb=35888b67f77fa7a5cae0973403cb97aa30cad70c diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml index 55b458557..317fbf1f2 100644 --- a/man/systemd.timer.xml +++ b/man/systemd.timer.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.timer - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.timer - 5 - - - - systemd.timer - Timer unit configuration - - - - timer.timer - - - - Description - - A unit configuration file whose name ends in - .timer encodes information about - a timer controlled and supervised by systemd, for - timer-based activation. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. The - timer specific configuration options are configured in - the [Timer] section. - - For each timer file, a matching unit file must - exist, describing the unit to activate when the timer - elapses. By default, a service by the same name as the - timer (except for the suffix) is activated. Example: a - timer file foo.timer activates a - matching service foo.service. The - unit to activate may be controlled by - Unit= (see below). - - Unless DefaultDependencies= - is set to , all timer units will - implicitly have dependencies of type - Conflicts= and - Before= on - shutdown.target to ensure that - they are stopped cleanly prior to system shutdown. - Timer units with at least one - OnCalendar= directive will have an - additional After= dependency on - timer-sync.target to avoid - being started before the system clock has been - correctly set. Only timer units involved with early - boot or late system shutdown should disable the - DefaultDependencies= option. - - - - Options - - Timer files must include a [Timer] section, - which carries information about the timer it - defines. The options specific to the [Timer] section - of timer units are the following: - - - - OnActiveSec= - OnBootSec= - OnStartupSec= - OnUnitActiveSec= - OnUnitInactiveSec= - - Defines monotonic timers - relative to different starting points: - OnActiveSec= defines a - timer relative to the moment the timer - itself is - activated. OnBootSec= - defines a timer relative to when the - machine was booted - up. OnStartupSec= - defines a timer relative to when - systemd was first - started. OnUnitActiveSec= - defines a timer relative to when the - unit the timer is activating was last - activated. OnUnitInactiveSec= - defines a timer relative to when the - unit the timer is activating was last - deactivated. - - Multiple directives may be - combined of the same and of different - types. For example, by combining - OnBootSec= and - OnUnitActiveSec=, it is - possible to define a timer that - elapses in regular intervals and - activates a specific service each - time. - - The arguments to the directives - are time spans configured in - seconds. Example: "OnBootSec=50" means - 50s after boot-up. The argument may - also include time units. Example: - "OnBootSec=5h 30min" means 5 hours and - 30 minutes after boot-up. For details - about the syntax of time spans, see - systemd.unit5. - - If a timer configured with - OnBootSec= or - OnStartupSec= is - already in the past when the timer - unit is activated, it will immediately - elapse and the configured unit is - started. This is not the case for - timers defined in the other - directives. - - These are monotonic timers, - independent of wall-clock time and timezones. If the - computer is temporarily suspended, the - monotonic clock stops too. - - If the empty string is assigned - to any of these options, the list of - timers is reset, and all prior - assignments will have no - effect. - - Note that timers do not - necessarily expire at the precise - time configured with these settings, - as they are subject to the - AccuracySec= - setting below. - - - - - OnCalendar= - - Defines realtime - (i.e. wallclock) timers with calendar - event expressions. See - systemd.time7 - for more information on the syntax of - calendar event expressions. Otherwise, - the semantics are similar to - OnActiveSec= and - related settings. - - Note that timers do not - necessarily expire at the precise - time configured with this setting, - as it is subject to the - AccuracySec= - setting below. - - - - AccuracySec= - - Specify the accuracy - the timer shall elapse with. Defaults - to 1min. The timer is scheduled to - elapse within a time window starting - with the time specified in - OnCalendar=, - OnActiveSec=, - OnBootSec=, - OnStartupSec=, - OnUnitActiveSec= or - OnUnitInactiveSec= - and ending the time configured with - AccuracySec= - later. Within this time window, the - expiry time will be placed at a - host-specific, randomized but stable - position that is synchronized between - all local timer units. This is done in - order to distribute the wake-up time - in networked installations, as well as - optimizing power consumption to - suppress unnecessary CPU wake-ups. To - get best accuracy, set this option to - 1us. Note that the timer is still - subject to the timer slack configured - via - systemd-system.conf5's - TimerSlackNSec= - setting. See - prctl2 - for details. To optimize power - consumption, make sure to set this - value as high as possible and as low - as necessary. - - - Unit= - - The unit to activate - when this timer elapses. The argument is a - unit name, whose suffix is not - .timer. If not - specified, this value defaults to a - service that has the same name as the - timer unit, except for the - suffix. (See above.) It is recommended - that the unit name that is activated - and the unit name of the timer unit - are named identically, except for the - suffix. - - - - - Persistent= - - Takes a boolean - argument. If true, the time when the - service unit was last triggered is - stored on disk. When the timer is - activated, the service unit is - triggered immediately if it would have - been triggered at least once during - the time when the timer was inactive. - This is useful to catch up on missed - runs of the service when the machine - was off. Note that this setting only - has an effect on timers configured - with OnCalendar=. - - - - - WakeSystem= - - Takes a boolean - argument. If true, an elapsing timer - will cause the system to resume from - suspend, should it be suspended and if - the system supports this. Note that - this option will only make sure the - system resumes on the appropriate - times, it will not take care of - suspending it again after any work - that is to be done is - finished. Defaults to - false. - - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.service5, - systemd.time7, - systemd.directives7, - systemd-system.conf5, - prctl2 - - + + systemd.timer + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.timer + 5 + + + + systemd.timer + Timer unit configuration + + + + timer.timer + + + + Description + + A unit configuration file whose name ends in + .timer encodes information about a timer + controlled and supervised by systemd, for timer-based + activation. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The timer specific configuration options are + configured in the [Timer] section. + + For each timer file, a matching unit file must exist, + describing the unit to activate when the timer elapses. By + default, a service by the same name as the timer (except for the + suffix) is activated. Example: a timer file + foo.timer activates a matching service + foo.service. The unit to activate may be + controlled by Unit= (see below). + + Unless DefaultDependencies= is set to + , all timer units will implicitly have + dependencies of type Conflicts= and + Before= on shutdown.target + to ensure that they are stopped cleanly prior to system shutdown. + Timer units with at least one OnCalendar= + directive will have an additional After= + dependency on timer-sync.target to avoid + being started before the system clock has been correctly set. Only + timer units involved with early boot or late system shutdown + should disable the DefaultDependencies= + option. + + + + Options + + Timer files must include a [Timer] section, which carries + information about the timer it defines. The options specific to + the [Timer] section of timer units are the following: + + + + OnActiveSec= + OnBootSec= + OnStartupSec= + OnUnitActiveSec= + OnUnitInactiveSec= + + Defines monotonic timers relative to different + starting points: OnActiveSec= defines a + timer relative to the moment the timer itself is activated. + OnBootSec= defines a timer relative to when + the machine was booted up. OnStartupSec= + defines a timer relative to when systemd was first started. + OnUnitActiveSec= defines a timer relative + to when the unit the timer is activating was last activated. + OnUnitInactiveSec= defines a timer relative + to when the unit the timer is activating was last + deactivated. + + Multiple directives may be combined of the same and of + different types. For example, by combining + OnBootSec= and + OnUnitActiveSec=, it is possible to define + a timer that elapses in regular intervals and activates a + specific service each time. + + The arguments to the directives are time spans + configured in seconds. Example: "OnBootSec=50" means 50s after + boot-up. The argument may also include time units. Example: + "OnBootSec=5h 30min" means 5 hours and 30 minutes after + boot-up. For details about the syntax of time spans, see + systemd.unit5. + + If a timer configured with OnBootSec= + or OnStartupSec= is already in the past + when the timer unit is activated, it will immediately elapse + and the configured unit is started. This is not the case for + timers defined in the other directives. + + These are monotonic timers, independent of wall-clock + time and timezones. If the computer is temporarily suspended, + the monotonic clock stops too. + + If the empty string is assigned to any of these options, + the list of timers is reset, and all prior assignments will + have no effect. + + Note that timers do not necessarily expire at the + precise time configured with these settings, as they are + subject to the AccuracySec= setting + below. + + + + + OnCalendar= + + Defines realtime (i.e. wallclock) timers with + calendar event expressions. See + systemd.time7 + for more information on the syntax of calendar event + expressions. Otherwise, the semantics are similar to + OnActiveSec= and related settings. + + Note that timers do not necessarily expire at the + precise time configured with this setting, as it is subject to + the AccuracySec= setting + below. + + + + AccuracySec= + + Specify the accuracy the timer shall elapse + with. Defaults to 1min. The timer is scheduled to elapse + within a time window starting with the time specified in + OnCalendar=, + OnActiveSec=, + OnBootSec=, + OnStartupSec=, + OnUnitActiveSec= or + OnUnitInactiveSec= and ending the time + configured with AccuracySec= later. Within + this time window, the expiry time will be placed at a + host-specific, randomized but stable position that is + synchronized between all local timer units. This is done in + order to distribute the wake-up time in networked + installations, as well as optimizing power consumption to + suppress unnecessary CPU wake-ups. To get best accuracy, set + this option to 1us. Note that the timer is still subject to + the timer slack configured via + systemd-system.conf5's + TimerSlackNSec= setting. See + prctl2 + for details. To optimize power consumption, make sure to set + this value as high as possible and as low as + necessary. + + + Unit= + + The unit to activate when this timer elapses. + The argument is a unit name, whose suffix is not + .timer. If not specified, this value + defaults to a service that has the same name as the timer + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + timer unit are named identically, except for the + suffix. + + + + + Persistent= + + Takes a boolean argument. If true, the time + when the service unit was last triggered is stored on disk. + When the timer is activated, the service unit is triggered + immediately if it would have been triggered at least once + during the time when the timer was inactive. This is useful to + catch up on missed runs of the service when the machine was + off. Note that this setting only has an effect on timers + configured with OnCalendar=. + + + + + WakeSystem= + + Takes a boolean argument. If true, an elapsing + timer will cause the system to resume from suspend, should it + be suspended and if the system supports this. Note that this + option will only make sure the system resumes on the + appropriate times, it will not take care of suspending it + again after any work that is to be done is finished. Defaults + to false. + + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.service5, + systemd.time7, + systemd.directives7, + systemd-system.conf5, + prctl2 + +