Crond Daemon Process

Linux System Task Scheduler
/etc/crontab Cron Master configuration file, you can define path
The cron format is as follows:
#.----------------minutes (0-59)
# |.-------------hours (0-23)
# | |.----------Day (1-31)
# | | |.-------month (1-12)
# | | | |.----week (0-6) (Sunday =0 or 7)
# | | | | |
# * * * * * * user-name command to be executed
Cron is also a service, so you need to start the service before it takes effect:
service Crond start; service Crond status

Task Schedule Exercises:
Clear/var/log/slow.log This file every 1:20 A.M.
Crontab–e is the editor of this file ============
1 * * * echo "" >/var/log/show.log

Execute "/bin/sh/usr/local/sbin/backup.sh" every Sunday 3 o'clock
0 3 * * 0/bin/sh/usr/local/sbin/backup.sh

14th # 4:10 per month to execute "/bin/sh/usr/local/sbin/backup_month.sh"
4 * */bin/sh/usr/local/sbin/backup_month.sh

Perform "Ntpdate time.windows.com" every 8 hours
0 */8 * * * ntpdate time.windows.com
Or
0 0,8,16 * * * ==0,8,16 These three are a segment

1 points per day, 12 points, 18 points to execute "/bin/sh/usr/local/sbin/test.sh"
0 1,12,18 * * */bin/sh/usr/local/sbin/test.sh

"/bin/sh/usr/local/sbin/test2.sh" is executed from 9 to 18 every day.
0 9-18 * * */bin/sh/usr/local/sbin/test2.sh

Daemon process

Pstree

Service Crond Stop
Service Crond Start Restart is reboot reload reload

Control Interface for NTSYSV services

Chkconfig configuration daemon in which mode to start

Chkconfig--list View all related daemons
Chkconfig--list Crond View Individual
Chkconfig--level 2345 Crond off changing the status of the process

Crontab-l viewing a user's cron task

Recurring Scheduled Tasks (automate)

Service Crond status to see if a daemon is running

Crontab-e
*/1 * * * * echo "weclome to Houdunwang." >>/hd.txt Print to hd.txt once a minute
Crontab-l Viewing task Schedules
Cat Hd.txt Look at the number of prints in there.

Crontab-r is emptying the scheduled task
Service Crond Restart Restart it will not take effect hd.txt not print

Vim/etc/cron.deny write which user in it which user cannot use Crontab

Use of crontab for ordinary users
Crontab-e
*/1 * * * * echo "weclome to Houdunwang." >>/home/zhangsan/hd.txt

Crontab-l
Sudo/sbin/service crond Restart Normal user to restart this way
Sudo/sbin/service crond Status

Let Linux auto sync time (Shunz)

Vi/etc/crontab
Add one sentence:
XX 0 1 * * Root rdate-s time.nist.gov

By specifying a time, the command is executed whenever the current time is matched. For example, by specifying the following time: 0 * * * * do-something, the command will be executed at the current time with a minute value of 0 o'clock (for example, the hour).

Instead, specify the following time: 0 * * * do-something, the command will run every 11 o'clock in the evening.

If multiple values are specified, each value is matched. For example, to execute a command every 15 minutes, use the following statement:
0,15,30,45 * * * * do-something

Alternatively, you can specify the command to run every six hours from Monday to Friday by using the following command:
0 0,6,12,18 * * 1,2,3,4,5 do-something

You can include as many rows in crontab as you want, and you can refer to the same command multiple times, which is quite difficult to implement in other cases. For example, a command that runs at 6 o'clock in the afternoon Monday to Thursday, but runs at lunchtime in Friday, can use the following two lines of statements:
0 * * 1,2,3,4 do-something
0 * * 5 do-something
===============================
Care should be taken with respect to the first two options (minutes and hours), and if you do not specify both options (using the asterisk), it will cause the other specified values to run once per minute. For example, a common mistake would be to run the command at the beginning of the month, but use the following statement:
* * 1 * * do-something

The problem here is that the specified statement will actually run the command once every minute on the first day of the month. If you want the command to run only once, you must specify a value for the minute and time that the command should be executed:
0 1 * * do-something
=================================
Omitting the minute value will let the command run the command at least once per minute, when matching the specified time (and date).

Despite this flexibility, there are still situations where it is difficult (and even impossible) to execute commands using the crontab system.

Working with manual schedules

The problem with Cron is that while all the different options available in Crontab offer a variety of possibilities, there are still some annoying limitations.

Last day of the month

For example, it is difficult to run the command on the last day of the month in Cron because there is no way to specify this information directly. Instead, you must specify the month separately and its corresponding last day. For example, in a year that is not leap years, you can use the following three lines of statements together:
1,3,5,7,8,10,12 * do-something
4,6,9,11 * do-something
2 * do-something

==============================
In the example above, the last day of each month is selected manually, but managing these three lines can be cumbersome, and you must manually modify the crontab definition in a leap year to ensure that the information calculates the correct date.

The workaround is to perform a date check using the echo command instead of cron. To do this, you need to use a CAL (for outputting the calendar for the current month) and awk (to determine the last day of the month). If you run the following command, you should get the last day of the month:
$ Echo ' cal ' |awk ' {print $NF} '

The above command first outputs the calendar through the Echo command (which outputs the usual multiline output as a row), and then counts the number of outputs, and the last number is the last day of the current month.

To use this command in crontab, you should take the following approach:
* * * [' echo \ ' cal\ ' |awk ' {print $NF} '-eq ' date +\%d '] && do-something

The square brackets start a test in the shell that is used to run the command. Also note that Cron will filter out the% symbol, so it must be escaped when used in crontab. The first part of the test is what was shown earlier, and the second part uses the date command to output the current date. Duplicate && ensures that the command on the right side of && is executed only when the test result on the left is true.

A specific day in a given week

Another common requirement is to run only a specific number of weeks in a month. For example, you might want to run a report in the first Monday or Friday of each month. To complete this task, you can use a procedure similar to the above. For any day of a given week, it must fall into one of the following date ranges:

* 1th Week: 1th Day to 7th day
* 2nd week: 8th Day to 14th day
* 3rd week: 15th day to 21st day
* 4th week: 22nd Day to 28 days

To determine whether the current date is within a given range, such as whether it is within the fourth week range, you can use a test similar to the following:
[' Date +\%e '-gt 21-a ' date +\%e '-lt 29]

The%e is used to return the number of the day, and a space (instead of 0) is used as its prefix if the digit is less than 10 to ensure that the number (not the string) is compared.

You can now use this with the crontab definition to try to run the command every Friday:
* 5 [' Date +\%e '-gt 21-a ' date +\%e '-lt 29]
&& do-something

The command will run every Friday, but since the test will return True only on the fourth week of each month, the command will actually be executed in the third Friday.

Cron Job Execution Environment

Although you can change the environment that is used when you perform a cron job, it is often best to create a wrapper script that defines any environment variables (such as PATH) before you run the commands that you actually need.

Part of the reason for this is security considerations; the more areas open to cron jobs, the more likely it is to have something that contains suspicious content. Another reason is that you can ensure that even if you change one of the dependencies in your environment, your cron job will still execute.

By using separate wrapper scripts, you can also take advantage of the extensions and capabilities of different shell programs, not just the standard Bourne shell that is typically used to run most cron jobs.

Finally, by using a separate wrapper script, you also allow you to define different environments for different commands. This is useful if you want to run commands in different user environments that might use different versions of the same application or tool.

Tips for recording output

By default, commands for the build output that Crontab runs (output to standard output and standard errors) send the output as an e-mail message to the user of the job. However, this is not always a convenient solution, for some results you may only need partial output, or you may want to ignore standard output and report only errors. You might even want to send the output to a different user or e-mail alias.

You can use redirection in the CRONTAB specified statement to send output information to a specific file or to ignore output from a different source. To log output directly to a file, you can use the following statement:
1 1 * * * do-something >/var/logs/do-something.log

The above statement overwrites the information, so if you want to keep a record for a long time, use append:
1 1 * * * do-something >>/var/logs/do-something.log

to ignore the output, redirect to a special/dev/null device. For standard output, try the following statement:
1 1 * * * do-something >/dev/null

For standard output and errors, try the following statement:
1 1 * * * do-something >/dev/null 2>&1

If you want to collect logs organized by date, use the date command with the statement that specifies the log file, for example:
1 1 * * * do-something >/var/logs/something. ' Date +\%y\%m\%d '. Log

To pick and select output from a series of commands in Cronjob, or to create a custom content-based e-mail message, use a wrapper script to write the information you want to save to a temporary file, ignoring the other output. You can then send the contents of the file as an e-mail message to any desired user.

To create a temporary file, use the time and process ID to generate a unique file name, as follows:
logfile=/tmp/' datetime +%y%m%d '. $$.tempfile
do-something > $LOGFILE 2>&1
Mailx-s "Results of do-something Report" Reportees < $LOGFILE
Rm-f $LOGFILE

Once you have sent the file to the person concerned, remember to delete the file. In the example above, MAILX (not mail) was used to allow the theme to be set.

Conclusion

By using the crontab and AT commands together, you can specify the execution time or interval for any required commands. When using at, you can run only one command or script at a given time. By using crontab, you can specify the time interval for execution, which can be arbitrarily specified, can be very long, or can be very short-spaced. However, it should be handled carefully to ensure that the command runs at the exact time required. Ignoring the points can be problematic, or may cause your command to run at an expected time or time interval.

When crontab is not specific or flexible, there are other workarounds that can be used to handle more complex situations, such as running commands on the last day of the month or on a specific day of a particular week.

Planning can save time, and under careful organization, it can help reduce your workload and reduce duplication of effort.

Crond Daemon Process