Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to use systemd timer instead of cron homework". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to use systemd timer instead of cron homework".

Timers provide finer-grained event control than cron jobs.

I am working on migrating my cron jobs to systemd timers. I have been using timers for many years, but generally speaking, my knowledge is only enough to support my current job. But in the course of studying the systemd series, I found that systemd timers have some very interesting capabilities.

Similar to cron jobs, systemd timers can trigger events (shell scripts and programs) at specific intervals, such as once a day or on a specific day of the month (perhaps only effective on Monday), or every 15 minutes during working hours from 8 a.m. to 6 p.m. Timers can also do some things that cron jobs cannot do. For example, a timer can trigger a script or program to execute after a specific event, such as startup, startup, completion of the last task, or even the completion of the last service unit invoked by the timer.

Timer for operating system maintenance

When Fedora or any systemd-based distribution is installed on a new system, it creates multiple timers in the background of the Linux host as part of the system maintenance process. These timers trigger events to perform necessary routine maintenance tasks, such as updating system databases, cleaning temporary directories, rotating log files, and more.

As an example, I'll look at some timers on my main workstation and show all the timers on the host by executing the systemctl status * timer command. The asterisk works the same as the file wildcard, so this command lists all systemd timer units.

[root@testvm1] # systemctl status * timer ● mlocate-updatedb.timer-Updates mlocate database every day Loaded: loaded (/ usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left Triggers: ● mlocate-updatedb.service Jun 02 08:02:33 testvm1.both.org systemd [1]: Started Updates mlocate database every day. ● logrotate.timer-Daily rotation of log files Loaded: loaded (/ usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago Trigger: Fri 2020-06-05 00:00:00 EDT 15h left Triggers: ● logrotate.service Docs: man:logrotate (8) man:logrotate.conf (5) Jun 02 08:02:33 testvm1.both.org systemd [1]: Started Daily rotation of log files. ● sysstat-summary.timer-Generate summary of yesterday's process accounting Loaded: loaded (/ usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left Triggers: ● sysstat-summary.service Jun 02 08:02:33 testvm1.both.org systemd [1]: Started Generate summary of yesterday's process accounting. ● fstrim.timer-Discard unused blocks once a week Loaded: loaded (/ usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left Triggers: ● fstrim.service Docs: man:fstrim Jun 02 08:02:33 testvm1.both.org systemd [1]: Started Discard unused blocks once a week. ● sysstat-collect.timer-Run system activity accounting tool every 10 minutes Loaded: loaded (/ usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left Triggers: ● sysstat-collect.service Jun 02 08:02:33 testvm1.both.org systemd [1]: Started Run system activity accounting tool every 10 minutes. ● dnf-makecache.timer-dnf makecache-- timer Loaded: loaded (/ usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left Triggers: ● dnf-makecache.service Jun 02 08:02:33 testvm1.both.org systemd [1]: Started dnf makecache-timer. ● systemd-tmpfiles-clean.timer-Daily Cleanup of Temporary Directories Loaded: loaded (/ usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled) Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago Trigger: Fri 2020-06-05 08:19:00 EDT 23h left Triggers: ● systemd-tmpfiles-clean.service Docs: man:tmpfiles.d (5) man:systemd-tmpfiles (8) Jun 02 08:02:33 testvm1.both.org systemd [1]: Started Daily Cleanup of Temporary Directories.

Each timer has at least six lines of relevant information:

The first line of the timer contains a brief introduction to the name and purpose of the timer

The second line shows the status of the timer, whether it has been loaded, the full path to the timer unit file, and the preset information.

The third line indicates its activity status, including the date and time when the timer was activated.

The fourth line contains the date and time that the timer will be triggered next time and the approximate time from which the timer will be triggered.

The fifth line shows the name of the event or service triggered by the timer.

Some (but not all) of the systemd unit files have guidelines for related documentation. Three timers in the output on my virtual machine are documented. This is a good (but not necessary) message.

The last line is the log entry for the service instance that the timer recently triggered.

You may have some different timers, depending on your mainframe.

Create a timer

Although we can deconstruct one or more existing timers to understand how they work, let's create our own service unit and a timer to trigger it. To keep it simple, we will use a fairly simple example. When we finish this experiment, it will be easier to understand how other timers work and find out what they are doing.

First, create a simple service that runs the basics, such as the free command. For example, you might want to monitor free memory on a regular basis. Create the following myMonitor.server unit file in the / etc/systemd/system directory. It does not need to be an executable:

# This service unit is for testing timer units# By David Both# Licensed under GPL V2# [Unit] Description=Logs system statistics to the systemd journalWants=myMonitor.timer [Service] Type=oneshotExecStart=/usr/bin/free [Install] WantedBy=multi-user.target

This is probably the simplest service unit you can create. Now let's check the service status and test the service unit to make sure it is as available as we expected.

[root@testvm1 system] # systemctl status myMonitor.service ● myMonitor.service-Logs system statistics to the systemd journal Loaded: loaded (/ etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@testvm1 system] # systemctl start myMonitor.service [root@testvm1 system] #

Where is the output? By default, the standard output (STDOUT) of the systemd service unit executor is sent to the system log, which keeps the record for viewing now or later (until some point in time). In subsequent articles in this series, I will introduce the recording and retention policies of Syslog. Specifically check the log of your service unit, and only for today. The-S option, which stands for-- since, allows you to specify the time period for which the journalctl tool searches for items. That doesn't mean you don't care about past results-in this case, there will be no past records-it can shorten search time if your machine has been running for a long time and has accumulated a large number of logs.

[root@testvm1 system] # journalctl-S today-u myMonitor.service-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. -- Jun 11 09:12:09 testvm1.both.org systemd [1]: Starting Logs system statistics to the systemd journal...Jun 11 09:12:09 testvm1.both.org free [377966]: total used free shared buff/cache availableJun 11 09:12:09 testvm1.both.org free [377966]: Mem: 12635740 522868 11032860 8016 1080012 11821508Jun 11 09:12:09 testvm1.both.org free [ 377966]: Swap: 8388604 0 8388604Jun 11 09:12:09 testvm1.both.org systemd [1]: myMonitor.service: Succeeded. [root@testvm1 system] #

The task triggered by the service can be a single program, a set of programs, or a script written by a scripting language. You can add another task to the service by adding the following line to the end of the [Service] block in the myMonitor.service unit file:

ExecStart=/usr/bin/lsblk

Start the service again and view the log check results, which should look like this. You should see the output of the results of two commands in the log:

Jun 11 15:42:18 testvm1.both.org systemd [1]: Starting Logs system statistics to the systemd journal...Jun 11 15:42:18 testvm1.both.org free [379961]: total used free shared buff/cache availableJun 11 15:42:18 testvm1.both.org free [379961]: Mem: 12635740 531788 11019540 8024 1084412 11812272Jun 11 15:42:18 testvm1.both.org free [379961] : Swap: 8388604 0 8388604Jun 11 15:42:18 testvm1.both.org lsblk [379962]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTJun 11 15:42:18 testvm1.both.org lsblk [379962]: sda 8:0 0 120G 0 diskJun 11 15:42:18 testvm1.both.org lsblk [379962]: ├─ sda1 8:1 0 4G 0 part / bootJun 11 15:42:18 testvm1.both .org lsblk [379962]: └─ sda2 8:2 0 116G 0 partJun 11 15:42:18 testvm1.both.org lsblk [379962]: ├─ VG01-root 253:0 0 5G 0 lvm / Jun 11 15:42:18 testvm1.both.org lsblk [379962]: ├─ VG01-swap 253:1 0 8G 0 lvm [SWAP] Jun 11 15:42:18 testvm1.both.org lsblk [379962]: ├─ VG01-usr 253: 20 30G 0 lvm / usrJun 11 15:42:18 testvm1.both.org lsblk [379962]: ├─ VG01-tmp 253:3 0 10G 0 lvm / tmpJun 11 15:42:18 testvm1.both.org lsblk [379962]: ├─ VG01-var 253:4 0 20G 0 lvm / varJun 11 15:42:18 testvm1.both.org lsblk [379962]: └─ VG01-home 253:5 0 10G 0 lvm / homeJun 11 15:42: 18 testvm1.both.org lsblk [379962]: sr0 11:0 1 1024M 0 romJun 11 15:42:18 testvm1.both.org systemd [1]: myMonitor.service: Succeeded.Jun 11 15:42:18 testvm1.both.org systemd [1]: Finished Logs system statistics to the systemd journal.

Now that you know that your service is working as expected, create a myMonitor.timer timer unit file in the / etc/systemd/system directory and add the following code:

# This timer unit is for testing# By David Both# Licensed under GPL Venture [Unit] Description=Logs some system statistics to the systemd journalRequires=myMonitor.service [Timer] Unit=myMonitor.serviceOnCalendar=*-*-* *: *: 00 [Install] WantedBy=timers.target

The OnCalendar time format in the myMonitor.timer file, *-*-*: *: 00, should trigger a timer every minute to execute the myMonitor.service unit. I'll explore OnCalendar settings further later in the article.

So far, observe the logging associated with the service when it is triggered by a timer. You can also track the timer, and the tracking service allows you to see the results in close to real time. Execute journalctl with the-f option:

[root@testvm1 system] # journalctl-S today-f-u myMonitor.service-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --

Execute without enabling the timer and see what happens after it has been running for a period of time:

[root@testvm1 ~] # systemctl start myMonitor.service [root@testvm1 ~] #

One result is immediately displayed, and the next one is about a minute later. Look at the log for a few minutes to see if you found the same thing as me:

[root@testvm1 system] # journalctl-S today-f-u myMonitor.service-- Logs begin at Mon 2020-06-08 07:47:20 EDT. -- Jun 13 08:39:18 testvm1.both.org systemd [1]: Starting Logs system statistics to the systemd journal...Jun 13 08:39:18 testvm1.both.org systemd [1]: myMonitor.service: Succeeded.Jun 13 08:39:19 testvm1.both.org free [630566]: total used free shared buff/cache availableJun 13 08:39:19 testvm1.both.org free [630566]: Mem: 12635740 556604 10965516 8036 1113620 11785628Jun 13 08:39:19 testvm1.both.org free [630566]: Swap: 8388604 0 8388604Jun 13 08:39:18 testvm1.both.org systemd [1]: Finished Logs system statistics to the systemd journal.Jun 13 08:39:19 testvm1.both.org lsblk [630567]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTJun 13 08:39:19 testvm1.both.org lsblk [630567]: sda 8 : 0 0 120G 0 diskJun 13 08:39:19 testvm1.both.org lsblk [630567]: ├─ sda1 8:1 0 4G 0 part / bootJun 13 08:39:19 testvm1.both.org lsblk [630567]: └─ sda2 8:2 0 116G 0 partJun 13 08:39:19 testvm1.both.org lsblk [630567]: ├─ VG01-root 253:0 0 5G 0 lvm / Jun 13 08:39:19 testvm1.both.org Lsblk [630567]: ├─ VG01-swap 253:1 0 8G 0 lvm [SWAP] Jun 13 08:39:19 testvm1.both.org lsblk [630567]: ├─ VG01-usr 253:2 0 30G 0 lvm / usrJun 13 08:39:19 testvm1.both.org lsblk [630567]: ├─ VG01-tmp 253:3 0 10G 0 lvm / tmpJun 13 08:39:19 testvm1.both.org lsblk [630567]: ├─ VG01-var 253 : 40 20G 0 lvm / varJun 13 08:39:19 testvm1.both.org lsblk [630567]: └─ VG01-home 253:5 0 10G 0 lvm / homeJun 13 08:39:19 testvm1.both.org lsblk [630567]: sr0 11:0 1 1024M 0 romJun 13 08:40:46 testvm1.both.org systemd [1]: Starting Logs system statistics to the systemd journal...Jun 13 08:40:46 testvm1.both.org free [630572]: Total used free shared buff/cache availableJun 13 08:40:46 testvm1.both.org free [630572]: Mem: 12635740 555228 10966836 8036 1113676 11786996Jun 13 08:40:46 testvm1.both.org free [630572]: Swap: 8388604 0 8388604Jun 13 08:40:46 testvm1.both.org lsblk [630574]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTJun 13 08:40:46 testvm1.both.org lsblk [630574]: sda 8:0 0 120G 0 diskJun 13 08:40:46 testvm1.both.org lsblk [630574]: ├─ sda1 8:1 0 4G 0 part / bootJun 13 08:40:46 testvm1.both.org lsblk [630574]: └─ sda2 8:2 0 116G 0 partJun 13 08:40:46 testvm1.both.org lsblk [630574]: ├─ VG01- Root 253:0 0 5G 0 lvm / Jun 13 08:40:46 testvm1.both.org lsblk [630574]: ├─ VG01-swap 253:1 0 8G 0 lvm [SWAP] Jun 13 08:40:46 testvm1.both.org lsblk [630574]: ├─ VG01-usr 253:2 0 30G 0 lvm / usrJun 13 08:40:46 testvm1.both.org lsblk [630574]: ├─ VG01-tmp 253:3 0 10G 0 lvm / tmpJun 13 08:40:46 testvm1.both.org lsblk [630574]: ├─ VG01-var 253:4 0 20G 0 lvm / varJun 13 08:40:46 testvm1.both.org lsblk [630574]: └─ VG01-home 253:5 0 10G 0 lvm / homeJun 13 08:40:46 testvm1.both.org lsblk [630574]: sr0 11:0 1 1024M 0 romJun 13 08:40:46 testvm1.both.org systemd [1]: myMonitor.service: Succeeded.Jun 13 08:40:46 testvm1.both.org systemd [1]: Finished Logs system statistics to the systemd journal.Jun 13 08:41:46 testvm1.both.org systemd [1]: Starting Logs system statistics to the systemd journal...Jun 13 08:41:46 testvm1.both.org free [630580]: total used free shared buff/cache availableJun 13 08:41:46 testvm1.both.org free [630580]: Mem: 12635740 553488 10968564 8036 1113688 11788744Jun 13 08:41:46 testvm1.both.org free [630580]: Swap: 8388604 0 8388604Jun 13 08:41:47 testvm1.both.org lsblk [630581]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTJun 13 08:41:47 testvm1.both.org lsblk [630581]: sda 8:0 0 120G 0 diskJun 13 08:41:47 testvm1.both.org lsblk [630581]: ├─ sda1 8:1 0 4G 0 part / bootJun 13 08:41:47 testvm1.both.org lsblk [630581]: └─ sda2 8:2 0 116G 0 partJun 13 08:41:47 testvm1.both.org lsblk [630581]: ├─ VG01-root 253:0 0 5G 0 lvm / Jun 13 08:41:47 testvm1.both.org lsblk [630581]: ├─ VG01-swap 253:1 0 8G 0 lvm [ SWAP] Jun 13 08:41:47 testvm1.both.org lsblk [630581]: ├─ VG01-usr 253:2 0 30G 0 lvm / usrJun 13 08:41:47 testvm1.both.org lsblk [630581]: ├─ VG01-tmp 253:3 0 10G 0 lvm / tmpJun 13 08:41:47 testvm1.both.org lsblk [630581]: ├─ VG01-var 253:4 0 20G 0 lvm / varJun 13 08:41:47 testvm1.both.org lsblk [630581]: └─ VG01-home 253:5 0 10G 0 lvm / homeJun 13 08:41:47 testvm1.both.org lsblk [630581]: sr0 11:0 1 1024M 0 romJun 13 08:41:47 testvm1.both.org systemd [1]: myMonitor.service: Succeeded.Jun 13 08:41:47 testvm1.both.org systemd [1]: Finished Logs system statistics to the systemd journal.

Don't forget to check the status of timers and services.

You probably noticed at least two things in the journal. First, you don't need to do anything specifically to store the STDOUT generated by ExecStart triggers in the myMonitor.service unit into the log. This is all part of the function of using systemd to run services. However, it does mean that you need to be careful with the scripts executed in the service unit and how much STDOUT they can produce.

Second, timers are not exactly executed every minute: 00 seconds, and the interval between each execution is not exactly one minute. This is a deliberate design, but you can change this behavior if necessary (if it's the only one that challenges the sensitive nerves of your system administrator).

This is designed to prevent multiple services from being triggered at exactly the same time. For example, you can use time formats such as Weekly,Daily. These shortcuts are defined to be executed at 00:00:00 on a certain day. When multiple timers are defined in this way, it is highly likely that they will be executed at the same time.

The systemd timer is deliberately designed to be triggered at a point in time that fluctuates randomly near a specified time to avoid triggering at the same time. They are triggered semi-randomly in a time window, which starts at the preset trigger time and ends one minute after the preset time. According to the man pages of systemd.timer, this trigger time is kept in a stable position relative to other defined timer units. You can see in the log entry that the timer is triggered immediately after it is started, and then in 46 or 47 seconds after each minute.

In most cases, this probabilistic jitter timer is fine. When scheduling tasks like performing backups, you only need them to run during off-hours, which is fine. The system administrator can choose a definite start time to ensure that it does not conflict with other tasks, such as a typical cron job time such as 01:05:00, but there is a wide range of time values to meet this. A minute-level randomness at the start time is often irrelevant.

However, for some tasks, the exact trigger time is a mandatory requirement. For such tasks, you can add the following declaration to the Timer block of the unit file to specify a higher precision of the trigger time span (accurate to less than microseconds):

AccuracySec=1us

The time span can be used to specify the desired precision and to define the time span of repeated or one-time events. It identifies the following units:

Usec,us, μ s

Msec,ms

Seconds,second,sec,s

Minutes,minute,min,m

Hours,hour,hr,h

Days,day,d

Weeks,week,w

Months,month,M (defined as 30.44days)

Years,year,y (defined as 365.25 days)

All timers in / usr/lib/systemd/system specify a looser time precision because precise time is less important. Look at the time format of the timers created by these systems:

[root@testvm1 system] # grep Accur / usr/lib/systemd/system/*timer/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h [root@testvm1 system] #

Take a look at the full contents of some timer unit files in the / usr/lib/systemd/system directory to see how they are built.

In this lab, it is not necessary to activate this timer at startup, but the following command can be set to boot:

[root@testvm1 system] # systemctl enable myMonitor.timer

The unit file you create does not need to be executable. You also do not need to enable the service because it is triggered by a timer. You can still manually trigger the service unit on the command line if you want. Try it, and then look at the log.

For more information about timer precision, event time specifications, and triggered events, see the man pages of systemd.timer and systemd.time.

Timer type

Systemd timers also have functions that are not found in cron, and cron is triggered only at certain, repetitive, specific dates and times. The systemd timer can be configured to trigger when the state of other systemd units changes. For example, a timer can be configured to be triggered after the system is powered on, started, or after a certain service unit is activated. These are called monotone timers. "monotonous" refers to a continuously growing counter or sequence. These timers are not persistent because they are reset each time they are started.

Table 1 lists some monotonous timers and a short definition of each timer, along with OnCalendar timers, which are not monotonous and are used to specify a certain time that may be repeated in the future. This information comes from the systemd.timer man page with some unimportant changes.

The definition of timer monotonicity OnActiveSec=X defines a timer related to the moment the timer is activated. OnBootSec=X defines a timer related to the startup time of the machine. OnStartupSec=X defines a timer related to the first startup of the service manager. For system timers, this timer is similar to OnBootSec= because the system service manager starts shortly after the machine starts. It is especially useful when configured with units running in each user service manager, because the user's service manager usually starts after the first login, not after the machine starts. OnUnitActiveSec=X defines a timer related to the last activation time of the timer to be activated. OnUnitInactiveSec=X defines a timer related to the last deactivation time of the timer to be activated. OnCalendar= defines a real-time (that is, clock) timer with date event expression syntax. Check the man page of systemd.time (7) for more syntax information related to calendar event expressions. In addition, its semantics are similar to those of OnActiveSec=. Table 1: systemd timer definition

Monotone timers can use the same abbreviated names as their time span, that is, the AccuracySec expression we mentioned earlier, but systemd converts these names into seconds. For example, let's say you want to specify that a timer triggers an event five days after the system starts; it might look like OnBootSec=5d. If the machine starts at 09:45:27 on 2020-06-15, this timer will trigger at 09:45:27 on or after 2020-06-20.

Calendar event format

The calendar event format is the key for timers to trigger at the required repetition time. Let's start by looking at some of the formats that OnCalendar settings use together.

Compared to the format in crontab, systemd and its timers use a different style of time and calendar format. It is more flexible than crontab and allows ambiguous dates and times in a way similar to the at command. It should also be familiar enough to make it easy to understand.

The basic format in which systemd timers use OnCalendar= is DOW YYYY-MM-DD HH:MM:SS. DOW (day of the week) is optional, and other fields can match any value at this location with an asterisk (*). All calendar time formats are converted to standard format. If no time is specified, it is set to 00:00:00. If the date is not specified but the time is specified, the next matching time may be today or tomorrow, depending on the current time. You can use names or numbers for months and weeks. Each unit can be separated by a comma list. The cell range can be used between the start and end values.. Specify.

There are some interesting options for specifying a date, and the tilde (~) can specify the last day of the month or a few days before the last day. Can be used to specify the day of the week as a modifier.

Here are several examples of typical time formats used in OnCalendar expressions.

Date event format describes DOW YYYY-MM-DD HH:MM:SS*-*-* 00:15:30 every day every day 00:15:30 Weekly every Monday 00:00:00Mon *-* * 00:00:00 ditto Mon Mon 2020 Mon every Wednesday in 2021 every working day (Monday to Friday) 00:00:00Mon..Fri 2021 in 2021 (Monday to Friday) 8-1 01:15:00Mon *-050.003 from June, July, August 1st to 15th of June, July and August in 2022, the next Monday in May is also the penultimate day of the month end Mon..Fri *-080004 the penultimate day of the end of August in any year. It must also be the penultimate day of the working day *-05pm 03 / February, and then come again 2 days later. Repeat it every year. Notice that this expression uses the tilde (~). *-05-03 March February the third day of May, then repeat every two days until the end of May. Notice that this expression uses a dash (-). Table 2: example of OnCalendar event time format

Test Calendar format

Systemd provides an excellent tool for detecting and testing the format of calendar time events in timers. The systemd-analyze calendar tool parses a time event format, providing a standard format and other interesting information, such as the next "elapsed" (that is, matching) date and time, as well as the approximate time before the next trigger.

First, take a look at the days when there is no time in the future (note that the time of Next elapse and UTC will change according to your local time zone):

[student@studentvm1] $systemd-analyze calendar 2030-06-17 Original form: 2030-06-17 Normalized form: 2030-06-17 00:00:00 Next elapse: Mon 2030-06-17 00:00:00 EDT (in UTC): Mon 2030-06-17 04:00:00 UTC From now: 10 years 0 months left [root@testvm1 system] #

Now add a time, in this case, the date and time are parsed separately as unrelated parts:

[root@testvm1 system] # systemd-analyze calendar 2030-06-17 15:21:16 Original form: 2030-06-17 Normalized form: 2030-06-17 00:00:00 Next elapse: Mon 2030-06-17 00:00:00 EDT (in UTC): Mon 2030-06-17 04:00:00 UTC From now: 10 years 0 months left Original form: 15:21:16 Normalized Form: *-- * 15:21:16 Next elapse: Mon 2020-06-15 15:21:16 EDT (in UTC): Mon 2020-06-15 19:21:16 UTC From now: 3h 55min left [root@testvm1 system] #

To analyze the date and time as a unit, you can enclose them in quotation marks. Remember to remove the quotation marks when you use the OnCalendar= time format in the timer unit, otherwise you will report an error:

[root@testvm1 system] # systemd-analyze calendar "2030-06-17 15:21:16" Normalized form: 2030-06-17 15:21:16 Next elapse: Mon 2030-06-17 15:21:16 EDT (in UTC): Mon 2030-06-17 19:21:16 UTC From now: 10 years 0 months left [root@testvm1 system] #

Now let's test the example in Table2. I especially like the last one:

[root@testvm1 system] # systemd-analyze calendar "2022-6 Original form 8-1 root@testvm1 system 15 01:15:00" Original form: 2022-6 Gravity 8-1 months left 15 01:15:00Normalized form: 2022-06 07 months left 08-01 15 01:15:00 Next elapse: Wed 2022-06-01 01:15:00 EDT (in UTC): Wed 2022-06-01 05:15:00 UTC From now: 1 years 11 months left [root@testvm1 system] #

Let's look at an example in which we list five elapsed times of the time expression.

[root@testvm1] # systemd-analyze calendar-- iterations=5 "Mon *-0534" Original form: Mon *-05003 Normalized form: Mon *-050003 00:00:00 Next elapse: Mon 2023-05-29 00:00:00 EDT (in UTC): Mon 2023-05-29 04:00:00 UTC From now: 2 years 11 months left Iter. # 2: Mon 2028-05-29 00:00:00 EDT (in UTC): Mon 2028-05-29 04:00:00 UTC From now: 7 years 11 months left Iter. # 3: Mon 2034-05-29 00:00:00 EDT (in UTC): Mon 2034-05-29 04:00:00 UTC From now: 13 years 11 months left Iter. # 4: Mon 2045-05-29 00:00:00 EDT (in UTC): Mon 2045-05-29 04:00:00 UTC From now: 24 years 11 months left Iter. # 5: Mon 2051-05-29 00:00:00 EDT (in UTC): Mon 2051-05-29 04:00:00 UTC From now: 30 years 11 months left [root@testvm1] #

This should provide you with enough information to start testing your OnCalendar time format. The systemd-analyze tool can be used for other interesting analyses, which I'll explore in the next article in this series.

Summary

Systemd timers can be used to perform the same tasks as the cron tool, but provide more flexibility by triggering events in a calendar and monotonous time format.

Although the service unit you create for this experiment is usually called by a timer, you can use the systemctl start myMonitor.service command to trigger it at any time. Multiple maintenance tasks can be scripted in a timer; they can be Bash scripts or other Linux programs. You can run all scripts to run services by triggering timers, or you can execute separate scripts as needed.

I will explore the usefulness of the systemd time format in more depth in the next article.

I haven't seen any indication that cron and at will be abandoned. I hope this won't happen, because at least at is much easier to perform one-time scheduling tasks than systemd timers.

Thank you for your reading, the above is the content of "how to use systemd timer instead of cron homework". After the study of this article, I believe you have a deeper understanding of how to use systemd timer instead of cron homework, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.