System Management: experience in using the task scheduling work plan

Task scheduling is a useful system management tool in both Linux and Windows operating systems. For example, you can schedule the task so that the operating system can automatically monitor the hard disk

Task scheduling is a useful system management tool in both Linux and Windows operating systems. For example, you can schedule the task so that the operating system can automatically monitor the disk usage. Statistics are collected once a day. if the disk space is less than 5%, reports are automatically reported to the system administrator. Therefore, as a qualified system administrator, you must have an in-depth understanding of the application of this tool. Specifically, the following content should be emphasized by the author.

1. properly locate the output results of the Task Scheduler

By default, the task scheduler outputs two types of results, namely running results (if the command defines the output results) and error messages (for example, error messages indicating that the task plan is not running properly. For the result information, the system administrator needs to specify whether or not the information is required and where the information is stored.

In the Linux operating system, normal result information can be displayed without error information, or both of them can be displayed. Even nothing can be displayed. The specific information is defined according to the requirements of the system administrator. For example, if the correct result information is used, the reading speed can be reduced, but some system error messages may be ignored. Generally, if the Linux operating system is used as a server, this task scheduling is related to important tasks, such as data backup. In this case, it is best to report the correct results to the system administrator at the same time (for example, when to start the score, how long it took, and the size of the backup file) and some error messages (including user-defined and default system error messages ). Because Linux servers do not have a lot in the enterprise, even if these error messages or normal results are added, the final reading volume will not increase much. In a common client system, only necessary information can be reported, such as whether the task plan is completed normally. Because the number of clients is large, if the response is complete, the system administrator does not have time to read the information. It may be directly put into the garbage bin. In this case, it is better to show only the content that the system administrator is interested in.

In addition to determining which content to display, the system administrator also needs to determine the display method. For example, by default, the system sends the execution result and error message to the user requesting the execution (if the email and other information are set correctly ). However, the system administrator can change the display mode. For example, the system administrator may find it troublesome to receive an email each time. If an enterprise has 100 clients (using CRON to back up important files on each client), the system administrator will receive 100 emails every day. Does this change to spam? Therefore, after many system administrators deploy CRON on the client, the related configuration will be changed. For example, the system administrator can save the result information or error log information to a local file. If you only need to add program>/home/user/log.txt. Note: In this case, only the result information is saved to this file, rather than the error information. If you want to save the normal running result and the error message, the system administrator must add 2> & 1 after the command. This 2> & 1 indicates the execution result and error message. Otherwise, the execution result is saved by default. However, sometimes the system administrator may not need this information at all (although the author does not suggest this, but some system administrators still have blind confidence in themselves), then the screen can also be dropped. In fact, I mentioned this shielding method in my previous articles, that is, using a special file/del/null in the system. When you need to filter some on-screen prompts (such as normal data streams or error messages), you can redirect related records to this file. For this purpose, the statement used by the author is program>/dev/null 2> & 1. After this command is executed, all information is redirected to the/dev/null file. This is an empty file in the system. Contents redirected to this file are not saved. Note that 2> & 1 must be added here. Otherwise, only part of the content will be blocked and some information will still be prompted as the system administrator.

I finally stressed that although some methods can be used in the system to shield the execution result or error information of the crond task plan, I generally do not recommend this. If this information is not available, it is difficult for the system administrator to determine whether the task plan is successfully executed. If you plan a job to complete the data backup function, you may need to query the attributes of the backup file one by one to determine whether the backup job is running correctly. This obviously increases the difficulty of maintenance. Therefore, you must keep the execution result or error message if necessary. If you feel that emails are troublesome, you can at least save the information to the local log file. It is convenient to view the information as needed.

II. use the crontab-r command with caution when deleting a task plan

When the system administrator no longer needs to regularly execute jobs defined in task scheduling, the crontab-r command can be used to delete jobs. Exercise caution when using this command. Because different task scheduling plans may be set in the same operating system. For example, one plan is used to back up the database, and the other plan is used to monitor the hard disk space occupied by the mail system. In this case, if the system administrator does not need to monitor the task plan of the email space (the email server may be transplanted to another server), the task plan needs to be deleted. If you use the crontab-r command to delete unnecessary task plans, the system administrator will regret it. Because this command deletes all task scheduling tasks, the task plans backed up from the above databases are also deleted. However, the system administrator did not want to delete the plan.

Therefore, when you use this command to delete a task scheduling job, it is best to use the crontal-l command to query which task scheduling jobs are in the current system. And determine whether to delete all the scheduling tasks. If you want to delete all or only the task scheduling job to be deleted, you can use the preceding command. Otherwise, you cannot use this delete command. If you want to delete a single task plan, you 'd better modify the cron configuration file. Each task scheduling work plan occupies a record in the configuration file. The system administrator needs to delete or comment out the corresponding records (I suggest you comment out the scheduling tasks that are not currently used, rather than delete them ). The commented content has the same effect as the deleted content, because the system does not consider the commented content during execution.

In addition, the system administrator root privilege can be used to manage all users' task scheduling tasks. For example, the system administrator uses the mail account to manage the mail server and uses the account to create the preceding task scheduling job. In this case, the system administrator can use crontab-l-u mail to query all task scheduling tasks created by the mail user. Similarly, you can run the crontab-r-u mail command to delete all task scheduling jobs created by this user. If you need to cancel this mail account, you can use this delete command to delete the corresponding task scheduling plan of this account at one time. If the account owner such as mail and oracle is actually the same person as the root account, that is, the system administrator assumes multiple roles at the same time, the author suggests using the root account to manage the task scheduling plan in a unified manner. If this is not the case, that is, there are database administrators and other employees in the enterprise to complete related maintenance work, it is best for each user to use their own account for maintenance. Unless it is a system administrator (privileged account), each account can only maintain its own task scheduling plan. This gives each user a relatively independent environment to avoid mutual interference.

It should be noted that it is better not to write too complex statements in the task plan. If you want to implement complex functions, such as counting the size of the backup file and the Directory of the backup file after backing up the file, you 'd better write them in a script file. Then let the task scheduling plan run the script file. It is difficult to execute complicated functions in the short code of the task scheduling plan. In addition, if you need to adjust the relevant functions in the future, you only need to adjust the script file. You do not need to modify the code of the original task scheduling. Obviously, this helps improve code flexibility.