Shulou(Shulou.com)05/31 Report--

The content of this article mainly focuses on what is the basis of using Systemd timer under the Linux system. The content of the article is clear and clear. It is very suitable for beginners to learn and is worth reading. Interested friends can follow the editor to read together. I hope you can get something through this article!

The following is an introduction to the Systemd timer (Systemd Timer) for scheduling tasks, which is also a basic article on using Systemd timers under Linux systems. It shows how to use timers in Systemd to run tasks repeatedly after the system starts and thereafter. Currently, Systemd has been providing timers for some time, and as an alternative to cron, this feature is worth seeing.

Cron vs anacron vs systemd

Cron can schedule tasks to run from a few minutes to months or more. Setting up is relatively simple and requires only one configuration file. Although the configuration line is a bit esoteric, it is also available to the average user.

However, if your system is not running when the appropriate execution time occurs, Cron will fail.

Anacron overcomes the problem of "the system is not running". It ensures that tasks will be performed when your system is active again. Although it is intended for use by administrators, some systems provide access to general users.

However, the frequency of anacron execution can be no less than that of each day.

Both cron and anacron have the problem of consistency of execution context. It is important to note that the valid environment in which the task runs is exactly the same as the environment used in testing. The same shell, environment variable, and path must be provided. This means that testing and debugging can be difficult sometimes.

Systemd timers provide the best features of cron and anacron. Allows scheduling to minute granularity. Ensure that the task will be executed when the system runs again, even if it is closed within the expected execution time. Available to all users. You can test and debug execution in the environment in which it will run.

However, the configuration is complex and requires at least two configuration files.

If your cron and anacron configurations serve you well, there may be no reason to change. But systemd is at least worth studying because it simplifies any current cron / anacron solution.

Reference: use Crontab UI security to manage Cron scheduled tasks under the Linux system.

Configuration

The function executed by the Systemd timer requires at least two files. They are "timer unit" and "service unit". The operation is not just a simple command, you also need a "job" file or script to perform the necessary functions.

The timer unit file defines the schedule, while the service unit file defines the tasks performed. For more details about the .timer unit, see "man systemd.timer". For more information about service units, see "man systemd.service".

The unit file exists in multiple locations (listed on the man page). However, for the average user, the simplest location may be "~ / .config / systemd/user". Note that the "user" here is the literal string "user".

Example

This example is a simple example of creating a user-scheduled job instead of a system-scheduled job (which will run as root). It prints the message, date, and time to a file.

1. First create a shell script that will execute the task. Create it in the local "bin" directory, for example, in "~ / bin/schedule-test.sh".

To create a file:

Touch ~ / bin/schedule-test.sh

Then add the following to the file you just created:

#! / bin/sh

Echo 'This is only a test: $(date)' > > $HOME/schedule-test-output.txt'

Remember to make your shell script executable.

2. Create a .service unit that will invoke the above script. Create directories and files in the "~ / .config/systemd/user/schedule-test.service" location:

[Unit] Description=A job to test the systemd scheduler[Service] Type=simpleExecStart=/home//bin/schedule- test.sh[Install] WantedBy=default.target

Note that it should be your @ HOME address, but the "user" in the unit file path name is actually the string "user".

The ExecStart line should provide an absolute address with no variables. One exception is that for user units, you can replace "% h" with $HOME. In other words, you can use:

ExecStart=%h/bin/schedule-test.sh

This is used only for subscriber unit files. This is bad for the system unit because "h" will always return "/ root" when running in the system environment. Other alternatives are found under the heading "SPECIFIERS" in "man systemd.unit". Because it's beyond the scope of this article, that's all we need to know about SPECIFIERS now.

3. Create a .timer unit file that actually dispatches the .service unit you just created. Create it in the same location as the .service file "~ / .config/systemd/user/schedule-test.timer". Note that the file name is only different in the extension, that is, ".service" and ".timer":

[Unit] Description=Schedule a message every 1 minuteRefuseManualStart=no # Allow manual startsRefuseManualStop=no # Allow manual stops [Timer] # Execute job if it missed a run due to machine being offPersistent=true#Run 120 seconds after boot for the first timeOnBootSec=120#Run every 1 minute thereafterOnUnitActiveSec=60#File describing job to executeUnit=schedule- test.service [install] WantedBy=timers.target Please note that the .timer file has used "OnUnitActiveSec" to specify the schedule. The "OnCalendar" option is more flexible. For example: # run on the minute of every minute every hour of every dayOnCalendar=*-*-* *: *: 0mm run on the hour of every hour of every dayOnCalendar=*-*-* *: 00run every dayOnCalendar=*-*-* 0mm run every dayOnCalendar=*-*-* 001V 0mm run 11:12:13 of the first or fifth day of any month of the year# 2012, but only if that day is a Thursday or FridayOnCalendar=Thu,Fri 2021Murray Thailand 5 11:12:13

4. All the parts are in place, but you should test to make sure everything is all right. First, enable user services:

$systemctl-user enable schedule-test.service

This should produce output similar to the following:

Created symlink / home//.config/systemd/user/default.target.wants/schedule-test.service → / home//.config/systemd/user/schedule-test.service.

Now run a test run on the job:

$systemctl-user start schedule-test.service

Check your output file ($HOME/schedule-test-output.txt) to make sure your script is executed correctly. Since we haven't started the timer yet, there should be an entry. Debug as needed. If you need to change the .service file instead of the shell script it calls, don't forget to enable the service again.

5. After the job is working properly, schedule it in real time by enabling and starting the user timer for your service:

$systemctl-user enable schedule-test.timer

$systemctl-user start schedule-test.timer

Note that you have started and enabled the service in step 4 above, so you only need to enable and start the timer for it.

The "enable" command results in output similar to the following:

Created symlink / home//.config/systemd/user/timers.target.wants/schedule-test.timer → / home//.config/systemd/user/schedule-test.timer.

And "start" only returns you to the CLI prompt.

Other actions

You can check and monitor services. The following first command is particularly useful if you receive an error from the service unit:

$systemctl-user status schedule-test

$systemctl-user list-unit-files

Stop the service manually:

$systemctl-user stop schedule-test.service

Permanently stop and disable timers and services, reload daemon configuration, and reset any failure notifications:

$systemctl-- user stop schedule-test.timer$ systemctl-- user disable schedule-test.timer$ systemctl-- user stop schedule-test.service$ systemctl-- user disable schedule-test.service$ systemctl-- user daemon-reload$ systemctl-- user reset-failed what is a Linux system Linux is a free to use and free dissemination of UNIX-like operating system, is a POSIX-based multi-user, multi-task, multi-thread and multi-CPU operating system Using Linux, you can run major Unix tools, applications, and network protocols.

Thank you for your reading. I believe you have a certain understanding of "what is the basis of using Systemd timers under the Linux system". Go and practice it. If you want to know more about it, you can follow the website! The editor will continue to bring you better articles!

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.