From Newsgroup: comp.os.linux.advocacy
On Wed, 22 Oct 2025 08:34:14 -0000 (UTC), w r wrote:
On Wed, 22 Oct 2025 02:01:52 -0000 (UTC), Lawrence D’Oliveiro wrote:
On Tue, 21 Oct 2025 03:19:50 -0000 (UTC), w r wrote:
... and it is loaded with features.
Such as?
http://fcron.free.fr/doc/en/fcrontab.5.html
1. Entries based on elapsed system up time ----------------------------------------------------
# Get our mails every 30 minutes @ 30 getmails -all
2. Some examples of entries based on time and date ----------------------------------------------------
# run mycommand at 12:05, 12:35, 13:05, 13:35,
# 14:05 *and* 14:35 everyday
systemd.timer(5) <
https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html>:
Table 1. Settings and their starting points
┌────────────────────┬───────────────────────────────────────┐
│ Setting │ Meaning │
├────────────────────┼───────────────────────────────────────┤
│ OnActiveSec= │ Defines a timer relative to the │
│ │ moment the timer unit itself is │
│ │ activated. │
├────────────────────┼───────────────────────────────────────┤
│ OnBootSec= │ Defines a timer relative to when the │
│ │ machine was booted up. In containers, │
│ │ for the system manager instance, this │
│ │ is mapped to OnStartupSec=, making │
│ │ both equivalent. │
├────────────────────┼───────────────────────────────────────┤
│ OnStartupSec= │ Defines a timer relative to when the │
│ │ service manager was first started. │
│ │ For system timer units this is very │
│ │ similar to OnBootSec= as the system │
│ │ service manager is generally started │
│ │ very early at boot. It's primarily │
│ │ useful when configured in units │
│ │ running in the per-user service │
│ │ manager, as the user service manager │
│ │ is generally started on first login │
│ │ only, not already during boot. │
├────────────────────┼───────────────────────────────────────┤
│ OnUnitActiveSec= │ Defines a timer relative to when the │
│ │ unit the timer unit is activating was │
│ │ last activated. │
├────────────────────┼───────────────────────────────────────┤
│ OnUnitInactiveSec= │ Defines a timer relative to when the │
│ │ unit the timer unit is activating was │
│ │ last deactivated. │
└────────────────────┴───────────────────────────────────────┘
Multiple directives may be combined of the same and of different
types, in which case the timer unit will trigger whenever any of
the specified timer expressions elapse. 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. Moreover, both monotonic time expressions and
OnCalendar= calendar expressions may be combined in the same timer
unit.
3. Entries run periodically (Ideal for laptops and desktops which are
not up 24/7)
----------------------------------------------------
# will run the command once each night either between 21:00 and 23:59,
or between 3:00 and 5:59 # (it will run as soon as possible. To change
that, use option random) and won't send mail (because option mail is set
to "no"). %nightly,mail(no) * 21-23,3-5 echo "a nightly entry"
From the same man page:
When a system is temporarily put to sleep (i.e. system suspend or
hibernation) the realtime clock does not pause. When a calendar
timer elapses while the system is sleeping it will not be acted on
immediately, but once the system is later resumed it will catch up
and process all timers that triggered while the system was
sleeping. Note that if a calendar timer elapsed more than once
while the system was continuously sleeping the timer will only
result in a single service activation. If WakeSystem= (see below)
is enabled a calendar time event elapsing while the system is
suspended will cause the system to wake up (under the condition the
system's hardware supports time-triggered wake-up functionality).
Also, how about this one:
RandomizedDelaySec=
...
This setting is useful to stretch dispatching of similarly
configured timer events over a certain time interval, to
prevent them from firing all at the same time, possibly
resulting in resource congestion on the local system.
Note the relation to AccuracySec= above: the latter allows the
service manager to coalesce timer events within a specified
time range in order to minimize wakeups, while this setting
does the opposite: it stretches timer events over an interval,
to make it unlikely that they fire simultaneously.
--- Synchronet 3.21a-Linux NewsLink 1.2