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

Table of contents:

(1) at plans tasks

(2) crontab plans tasks

(3) cleaning up temporary documents

Experienced system operation and maintenance engineers can make Linux system automatically start or stop some services or commands in a specified period of time without human intervention, so as to realize the automation of operation and maintenance. Although we now have a powerful script to perform some batch work, it is too painful if we still need to hit the enter key at two o'clock in the morning to execute the script. Therefore, this enables us to master how to set up the server's scheduled task service, and it is particularly important to have the skill of handing periodic and regular work to the system automatically.

Scheduled tasks are divided into one-time scheduled tasks and periodic scheduled tasks. For example, when the company personnel writes a holiday email and plans to send it to all employees at 10:00 on the last working day before the holiday, all we need is to plan tasks at once. If the database administrator needs to back up the business database at 2: 00 a. M. every day, what we need is to solve this requirement by scheduling tasks periodically.

(1) at plans tasks

(1. 1) at is an one-time scheduled task. As its name implies, a planned task is only executed once, and it is generally used to meet temporary work requirements. We can do this using the at command, as long as it is written in the format of "at time". If you want to see an one-time scheduled task that has been set up but not yet executed, you can use the "at-l" command; if you want to delete it, you can use the atrm task serial number. When you use the at command to set up one-time scheduled tasks, the default is an interactive approach.

(1. 2) the first to use "atq" or "at-l" to view a list of all scheduled tasks in the current system.

# atq

# at-l

The usage of the at command can be seen through the "man at" command. Now that our need is to create a scheduled task for October 27th 2019 (currently on the 26th), we can find a date representation that suits our usage habits, such as editors performing a scheduled task to restart the httpd service on October 27th. It is important to note that when our current time is, the created scheduled task will be executed when the date we specify is consistent with the current point in time. Because we created the scheduled task at 20:01 on October 26th, 2019, the scheduled task will be executed at 20:01 on October 27th, 2019.

# at 2019-10-27

At > systemctl restart httpd

(1.4) when creating a scheduled task at a specified time, we can also specify a specific time, accurate to time and minutes.

# at 22:00 2019-12-12 Murray-create a scheduled task to be executed at 22:00 on December 12, 2019

# at 4pm 2019-12-12 murmuri-create a scheduled task to be executed at 4: 00 p.m. on December 12, 2019

(1.5) if we want to execute the instruction to restart the http service at 4 pm in three weeks, we can use the weeks parameter; if we want to execute the instruction to restart the http service at 4 am three days later, we can use the days parameter; if we want to specify the instruction to restart the http service in 2 hours, we can use the hours parameter If we want to delete all files with the suffix rpm in the / root/ directory after 1 hour, we can use the minutes parameter.

# at 4pm + 3weeks

At > systemctl restart httpd

# at 4am + 3days

# at now + 2hours

# at now + 1minutes

At > rm-rf / root/*rpm

(1.6) if we want to query the information about a specific planned task, we can view it in two ways, the first is to use the "at-c" command to query (figure 1-6 and figure 1-7); the second is to go to the / var/spool/at directory to view the details of the planned task (figure 1-8 and figure 1-9).

# at-c 1

# cd / var/spool/at

(1.7) if we need to delete redundant scheduled tasks now, we can use the "atrm" command or the "at-d" command. If we want to bulk delete the specified scheduled task, we can use the

# atrm 1 Murray-Delete the first scheduled task

# at-d 2Murray-Delete the second scheduled task

# atrm {3... 6}-delete the 3rd to 6th scheduled tasks

(1.8) by default, ordinary users in the system can perform scheduled tasks. If our current requirement is to not allow ordinary users to perform scheduled tasks, we can add users to the / etc/at.deny file, for example, we do not allow tom users to query and create scheduled tasks, then refer to figure 1-12. At this time, tom users are no longer allowed to create and query plan tasks, and now we want tom users to create a query plan task. We can implement it in two ways. The first is to delete the tom user from the / etc/at.deny file. The second way is to create a / etc/at.allow file and add the tom user, because the system defaults to the settings in the / etc/at.allow file take effect when both / etc/at.allow and / etc/at.deny files exist for the same user (figure 1-13).

# vim / etc/at.deny

# vim / etc/at.allow

(2) crontab plans tasks

If we want the Linux system to perform certain specific tasks periodically and regularly, then the crond service enabled by default in the Linux system is simply appropriate. The command to create and edit a scheduled task is "crontab-e", the command to view the current scheduled task is "crontab-l", and the command to delete a scheduled task is "crontab-r". In addition, if you are logged on to the system as an administrator, you can add the-u parameter to the crontab command to edit other people's scheduled tasks.

(2.2) if we want to query the current user's scheduled tasks in the system, we can use "crontab-l". If we want to query the tom users' scheduled tasks in the system, we can use-u to indicate the user.

# crontab-LMMI-query the scheduled tasks of the current user in the system

# crontab-l-u tom--- queries tom users' scheduled tasks in the system

(2.3) if we want to edit the current user's scheduled task, we can use "crontab-e". If we want to edit the scheduled task for the specified user, we should add the option of "- u" (figure 2-3). Before we formally deploy the scheduled task, we need to recite the phrase "minute, hour, day, month, week, command". This is the parameter format for setting the task using the crond service. It is important to note that if some fields are not set, you need to use an asterisk (*) placeholder. For example, our current requirement is to plan to execute a script DeleteLock.sh at exactly 7 a.m. Every day, with the goal of finding all files with the suffix ".lock" under the / mail partition and clearing them (figures 2-4 to 2-6).

# crontab-e-u tom--- specifies that a scheduled task is created for tom users

Find / mail-type f-name "* .lock"-exec rm-rf {}\;-find all files under / mail partition with the suffix ".lock" and clear them

If our requirement is to execute the DeleteLock.sh script file on time from Monday to Friday morning at 7: 00 am, we can use the following three ways to express it.

(2.5) if our current requirement is to execute the DeleteLock.sh script file at 07:00, 5, 10, and 30 every morning, we can use the following representation.

Now our requirement is to execute the DeleteLock.sh script file at exactly 7 a.m. every day from Monday to Friday from January to March, which means that the command is executed on all working days from January to March (figure 2-9). Or our requirement is that we execute the DeleteLock.sh script file at exactly 7 a.m. on the 1st to 10th of every month from January to March (figure 2-10). When we combine the above two cases, we represent not intersection, but union, which means that the DeleteLock.sh script file will be executed from January to March on the 1st to 10th of each month or on all working days (figure 2-11).

If we want to see the scheduled tasks created, we can use the "crontab-l" command to query.

# crontab-lmurmuri-query all the created scheduled tasks

The scheduled tasks we created using crontab are saved in the / var/spool/cron/ directory, and we can go to the root file to view the details.

# cd / var/spool/cron/

(2.9) if we have a very complex business requirement, and there is no need to consider it when designing and planning tasks, we can split the complex requirement into several simple items to implement. For example, our current requirement is to execute the DeleteLock.sh script file at 2 a.m. on the last day of each month. We can create four entries in crontab, the first setting is to execute the DeleteLock.sh script on the 31st of each month in January, March, May, July, August, October and December, the second setting is to execute the DeleteLock.sh script on the 30th of each month in April, June, September and November, and the third is to create a script to execute the DeleteLock.sh script at 2: 00 a.m. on February 29th every year. Fourth, create a judgment script cc.sh to determine whether the year is a leap year on February 1st of each year. If it is a leap year, use the swd or awk command to set the date part to the 29th. If it is not a leap year, use the swd or awk command in the cc.sh script to replace the 29th with the 28th.

(2.10) there are also a lot of system tasks in our system. When we enter the / etc/ directory, we can see all the files at the beginning of cron*, in which "/ etc/cron.daily" represents daily scheduled tasks, "/ etc/cron.hourly" represents hourly scheduled tasks, and "/ etc/cron.monthly" represents monthly scheduled tasks. "/ etc/cron.weekly" represents the scheduled tasks that are performed each week. If we want to perform a specific scheduled task at a specific time, we can put the written script in the corresponding directory.

(2.11) if we need to delete the scheduled tasks created, we can use "crontab-r" to delete all scheduled tasks created by the root user.

# crontab-r

(2.12) ordinary users are allowed to create scheduled tasks by default in the system. If we want to restrict ordinary users from creating scheduled tasks, we can create a / etc/cron.deny file and fill in the user name that needs to be prohibited (figure 2-18). If we allow tom users to create scheduled tasks at this time, we can do so in two ways. the first is to delete the tom user in the / etc/cron.deny file. The second is that we create a / etc/cron.allow file again and fill in the tom user. At this time, we find that although the tom user is filled in both the / etc/cron.allow configuration file and / etc/cron.deny configuration file, the default is to take effect with the information in the / etc/cron.allow configuration file when the user exists at the same time (figure 2-19).

# vim / etc/cron.deny

(3) cleaning up temporary documents

(3.1) in the system, some temporary files of the system are often generated, for example, there are many files automatically generated by the system in the / tmp directory.

# ls / tmp/

(3.2) for example, our current requirement is to clean up all the system files generated 3 days ago. At this time, we first install the software corresponding to the tmpwatch command. We can use the man tmpwatch command to view the use of the parameters related to the tmpwatch command (figure 3-3). We delete all the files accessed 3 days ago in the current directory (figure 3-4). If we want to delete all files in the current directory that have not been accessed for more than 3 hours, we need to add the option of "- f" to force deletion (figure 3-5).

# yum install tmpwatch-y

# tmpwatch-u 3D.-delete all files accessed 3 days ago in the current directory

# tmpwatch-u 3h. -fmurmuri-delete all files in the current directory that have not been accessed for more than 3 hours

Of course, there are other tools to clear temporary files in our system, and a new service has been added to RHEL7 to manage temporary files.

# systemctl list-unit-files | grep systemd-tmpfi

(3.4) systemd-tmpfiles-setup.service this service can regularly clean some files and create some necessary files or directories regularly. Systemd-tmpfiles needs to read its own configuration files to know which temporary files to clean. The configuration files it needs to read are mainly placed in the following directory.

# ls / usr/lib/tmpfiles.d/--- saves files automatically generated by the system for systemd-tmpfiles to read. Generally speaking, it is not recommended that you modify the contents of them.

# ls / run/tmpfiles.d/--- saves files generated by the system daemon for systemd-tmpfiles to read, and we generally do not need to modify them

# ls / etc/tmpfiles.d/--- mainly stores some configuration files managed by users for systemd-tmpfiles to read. Generally, our custom configuration files are recommended to be placed in this directory.

(3.5) We create an aa.conf configuration file under the / etc/tmpfiles.d/ directory, specifying the created directory, the default permissions of the directory, the master group information of the directory, the timeout time to clean the files, and so on.

# cd / etc/tmpfiles.d/

The / tmp/aa directory is automatically created when we execute the systemd-tmpfiles command (figure 3-10). Then we go into the / tmp/aa directory to create a test.txt file, and then wait 10 seconds to execute the "clean" command, when we find that all the files in the / tmp/aa/ directory have been cleaned (figure 3-11).

# systemd-tmpfiles-clean

(3.7) if we create a directory rh224 and a file in the / tmp/aa directory, then wait 10 seconds to modify the last access time of the directory, and then perform the systemd-tmpfiles operation to clean up the temporary files again. At this time, because the rh224 directory does not exceed 10 seconds, and the file testRH124.txt file in the directory exceeds 10 seconds, after executing the command to clean up the files, we find that rh224 still exists, but the file testRH124.txt in the directory has been cleaned.

(3.8) because the information of all configuration files in the / usr/lib/tmpfiles.d/ directory, / run/tmpfiles.d/ directory, and / etc/tmpfiles.d/ directory will be read when the "systemd-tmpfiles" related command is executed. If we only want to read a specific configuration file for execution, we can specify a specific configuration file name at the end, such as indicating aa.conf, then entries in other configuration files will not be cleaned up.

# systemd-tmpfiles-- clean aa.conf--- We can add aa.conf to indicate that we are only performing cleaning entries in the aa.conf configuration file

Of course, after we create the aa.conf configuration file in the / etc/tmpfiles.d/ directory, the system will clean up the entries in the configuration file we created on a regular basis. Files that execute configuration files on a regular basis are stored in the / usr/lib/systemd/system directory (figure 3-14). For example, "OnBootSec=15min" indicates that the systemd-tmpfiles-clean operation will be performed 15 minutes after boot (figure 3-15). Of course, the execution scope of files that are executed periodically in the / usr/lib/systemd/system directory corresponds to entries in all configuration files in the / usr/lib/tmpfiles.d/ directory, / run/tmpfiles.d/ directory, and / etc/tmpfiles.d/ directory by default.

# cd / usr/lib/systemd/system

# vim systemd-tmpfiles-clean.timer

-this is the end of this article. Thank you for reading-

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.