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

This article mainly introduces how to make Crontab perform a task every second. It is very detailed and has a certain reference value. Friends who are interested must finish it!

Crontab is a scheduled scheduling configuration file under linux, through which we can make the system's programs, scripts, commands and tasks run cyclically at set times, intervals and cycles. The smallest granularity of time in Crontab is minutes. In other words, with Crontab configuration, we can make the target task execute at most once a minute, not more frequently, but only by other methods.

For example, what if you want a program to be executed every 30 seconds?

There are still some workarounds. One idea is to add two configurations to the Crontab, one is normal scheduling, which is executed every minute, and the other is to wait 30 seconds before execution.

# Need these to run on 30-sec boundaries, keep commands in sync.* / path/to/executable param1 param2* (sleep 30; / path/to/executable param1 param2)

This method feels a little stiff and weird, but it does work. This method can actually be simplified into one line:

* / bin/bash-l-c "/ path/to/executable; sleep 30; / path/to/executable"

Another way is to use the watch command:

$watch-- interval. 30 script_to_run_every_30_sec.sh

But watch is a command-line tool, and we can use the nohup command to make it run in the background.

SystemD timer

If we're using a linux system with SystemD, we can use SystemD timers to schedule programs at any granularity, down to nanosecond in theory-- a little crazy, of course. All in all, it is far more flexible in task scheduling than Cron-there is no need to use a crappy scheme like sleep.

Setting up a SystemD timer is slightly more complicated than a crontab with one-line configuration, but this approach is worth trying to better implement scheduling tasks with a granularity less than 'per minute'.

The implementation principle of SystemD timer is simply two parts: a system service and a SystemD timer. SystemD timers perform scheduling, while tasks are written in service.

Here's a simple example. The goal is to have the system logger output "Hello World" every ten seconds.

/ etc/systemd/system/helloworld.service

[Unit] Description=Say Helo [service] ExecStart=/usr/bin/logger-i Hello World

/ etc/systemd/system/helloworld.timer

[Unit] Description=Say Hello every 10 seconds[ timer] OnBootSec=10OnUnitActiveSec=10AccuracySec= 1ms [install] WantedBy=timers.targethelloworld.timer does not declare the name of service, so how does it relate to service? Yes, because they have the same name, they are all helloworld.

If you want the entire system to use this timer, these two files need to be placed under / etc/systemd/system. If you want to use it for a user, put it in ~ / .config / systemd/user. For this timer to run immediately, you need to execute the following command:

Systemctl enable-now helloworld.timer

The-now flag inside is for the timer to execute immediately. Otherwise, the operation will not be triggered until the system is rebooted or the user logs in.

The functions of the fields in the [Timer] section are as follows:

OnBootSec-the number of seconds after the system starts to start scheduling OnUnitActiveSec-the interval between repeatedly scheduling related service. It is this line configuration that determines the actions scheduled at the same time as cron job. AccuracySec-timer precision. The default is one minute, which is very similar to cron. Higher requirements can be required, but the increase in accuracy will lead to more system consumption and wake up CPU more frequently. The configuration above says 1ms, which is obviously not a smart decision. Usually we can set it to 1 (1 second), which is enough for our timer with a granularity of less than 1 minute. Also because of this, we will see that the output of "Hello World" messages when the actual program is running is often delayed by about 1 second. If you think the delay of about a second is not a problem, you should set it this way.

You will find that the SystemD timer is not the same as the Crontab timer-the task scheduling cycle is not set by the year, month, day, hour and minute cycle, but by the time we first executed it, each additional cycle. If we prefer Crontab-like time configuration, and SystemD timers are also supported, we need to remove OnBootSec and OnUnitActiveSec and replace them with OnCalendar. Here is an example:

OnCalendar=*-*-* *: *: 00, 10, 20, 20, 30, 40, 50.

Finally, it is added that by default, SystemD timers are associated with service by the same name, or you can pair them by specifying the Unit field in the [Timer] configuration if you prefer.

All of the above methods can achieve scheduled scheduling tasks with less than minute granularity. Each has its own advantages. The SystemD timer looks more formal, but a little more complicated. Although the Crontab+sleep approach is awkward, it is not incompetent for some small tasks.

The above is how to make Crontab perform all the contents of the task once a second. Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.