Setup of crontab timed tasks for Linux applications

The implementation of Linux timing tasks are: cron, Anacron, at, and so on, here mainly about cron services.

Noun Explanation:

Cron is the service name, Crond is a background process, and crontab is a custom-made scheduled task table.

Package Installation:

To use the Cron service, install the Vixie-cron package and the Crontabs package first, and the two packages function as follows:

The Vixie-cron package is the main program for Cron.
The Crontabs package is a program used to install, uninstall, or list tables used to drive the cron daemon.

To see if a cron package is installed: Rpm-qa|grep Vixie-cron

To see if the Crontabs package is installed: Rpm-qa|grep crontabs

If not, execute the following command to install the package (package must exist)
RPM-IVH vixie-cron-4.1-54.fc5*
RPM-IVH crontabs*

If you do not have a local installation package, you can install it online if you have a network connection

Yum Install Vixie-cron
Yum Install Crontabs

To see if the Crond service is running:

Pgrep Crond

Or

/sbin/service crond Status

Or

Ps-elf|grep crond|grep-v "grep"

Crond Service Operation Command:

/sbin/service Crond Start//Startup service
/sbin/service Crond stop//Shut down service
/sbin/service crond Restart//Restart service
/sbin/service Crond Reload//Reload Configuration

To configure a scheduled task:

Cron has two configuration files, one is a global profile (/etc/crontab), is for system tasks, and a set of configuration files generated by the crontab command (Files under/var/spool/cron), is for a user. Scheduled tasks can be configured to any one of them.

To view the global configuration profile configuration: Cat/etc/crontab

---------------------------------------------
Shell=/bin/bash
Path=/sbin:/bin:/usr/sbin:/usr/bin
Mailto=root
home=/

# Run-parts
* * * * * Root run-parts/etc/cron.hourly
4 * * * Root run-parts/etc/cron.daily
4 * * 0 root run-parts/etc/cron.weekly
4 1 * * Root run-parts/etc/cron.monthly
----------------------------------------------

To view scheduled tasks under a user: Crontab-l or cat/var/spool/cron/user name

Crontab task Configuration Basic format:
* * * * * command
Minutes (0-59) hours (0-23) Date (1-31) month (1-12) week (0-6, 0 for Sunday) command

The 1th column represents minutes 1~59 per minute with * or */1
The 2nd column represents the hour 1~23 (0 means 0 points)
The 3rd column represents the date 1~31
The 4th column represents the month 1~12
5th Column Identification Number Week 0~6 (0 = Sunday)
6th List of commands to run

In any of these values, an asterisk (*) can be used to represent all valid values. For example, an asterisk in a month value means that the command is executed monthly after other constraints have been met.
The short line between integers (-) specifies an integer range. For example, 1-4 means integers 1, 2, 3, 4.
Specify a list with a series of values separated by commas (,). For example, 3, 4, 6, 8 indicate these four specified integers.
A forward slash (/) can be used to specify the interval frequency. Adding/<integer> after a range means that integers can be skipped within the range. For example, 0-59/2 can be used to define every two minutes in the Minutes field. The interval frequency value can also be used with asterisks. For example, the value of */3 can be used in the month field to indicate that the task runs every three months.
The line starting with the pound sign (#) is a comment and will not be processed.

Example:

0 1 * * */home/testuser/test.sh
Call/home/testuser/test.sh every night 1 o'clock

*/10 * * * */home/testuser/test.sh
Call once every 10 clock/home/testuser/test.sh

* * * * */usr/local/etc/rc.d/lighttpd restart
The above example shows that 21:30 restarts Apache per night.

4 1,10,22 * */USR/LOCAL/ETC/RC.D/LIGHTTPD restart
The above example shows that 4:45 restarts Apache on the 1, 10, and 22nd of the month.

1 * * 6,0/USR/LOCAL/ETC/RC.D/LIGHTTPD restart
The above example shows that 1:10 restarts Apache every Saturday and Sunday.

0,30 18-23 * * */usr/local/etc/rc.d/lighttpd restart
The above example shows that Apache restarts every 30 minutes from 18:00 to 23:00 every day.

0 * * 6/USR/LOCAL/ETC/RC.D/LIGHTTPD restart
The above example shows the restart of Apache every Saturday at 11:00am.

* */1 * * * */usr/local/etc/rc.d/lighttpd restart
Restart Apache every hour

* 23-7/1 * * * */usr/local/etc/rc.d/lighttpd restart
From 11 o'clock to 7 in the morning, restart Apache every hour.

0 4 * mon-wed/usr/local/etc/rc.d/lighttpd restart
4th per month with 11-point restart from Monday to Wednesday Apache

0 4 1 Jan */usr/local/etc/rc.d/lighttpd restart
4-point restart of Apache on January 1

*/30 * * * */usr/sbin/ntpdate 210.72.145.44
Synchronize time every half hour

To configure the syntax for user timed tasks:

crontab [-U user]file

crontab [-u user] [-l|-r |-e][-i]

Parameters and Description:

crontab-u//setting up a cron service for a user

crontab-l//listing details of a user's cron service

crontab-r//Delete a cron service with no users

crontab-e//editing a user's cron service

Example:

Assuming the current user is root, to establish the root user's scheduled task

Crontab-e

Select Editor, edit timed task (this assumes the editor is VI)

Press I to enter edit mode

0 1 * * */root/test.sh

Press ESC to exit edit mode into normal mode, enter: X or: Wq Save exit

View the timed tasks you just entered

crontab-l or cat/var/spool/cron/root

Users other than the root user can use the Crontab tool to configure cron tasks. All user-defined crontab are saved in the/var/spool/cron directory and executed using the user who created them. To create a crontab project as a user, log on as the user, and then type the CRONTAB-E command to edit the user's crontab using the editor specified by the VISUAL or editor environment variable. The file uses the same format as the/etc/crontab. When a change to crontab is saved, the crontab file is saved according to the user name and written to the file/var/spool/cron/username.
The cron daemon examines changes in/etc/crontab files, etc/cron.d/directories, and/var/spool/cron directories every minute. If a change is found, they will be loaded into memory. This way, you do not have to restart the daemon when a crontab file changes.

Restart Crond:

/sbin/service Crond Restart

See if the Cron service works:

If we want to see if the timed task is on time call the run information that can be/var/log/cron

Cat/var/log/cron

Or

grep. *\.sh/var/log/cron

Search for. SH type file information
Or

Sed-n '/back.*\.sh/p '/var/log/cron
Format Sed-n '/character or regular expression/p ' file name

We see in the log whether there are appropriate invocation information at the agreed time, similar to the invocation information:

Sep 1:00:01 localhost crond[25437]: (Root) CMD (/root/test.sh)

See if the shell script is an error:

If the shell script is called on time in/var/log/cron and the expected results are not met, we suspect that the shell script is wrong

cat/var/spool/mail/User Name

Example:

Cat/var/spool/mail/root

test.sh

-------------------------

#!/bin/sh

echo "$ (date ' +%y-%m-%d%h:%m:%s ') Hello world!" >>/root/test.log

-------------------------

To trace the entire process of a shell call:

BASH-XV test.sh 2>test.log

The test.sh call process will be written to Test.log.

Or

Rewrite test.sh

-------------------------

#!/bin/sh

Set-xv

echo "$ (date ' +%y-%m-%d%h:%m:%s ') Hello world!" >>/root/test.log

-------------------------

Sh./test.sh 2>tt.log

The information crontab on the Internet is not implemented:

First, the reason for the script: In most cases, we have to believe in science, believe that computers, not ghosts, is the problem of our script, this problem caused crontab can not execute the probability of more than 70%. Since the execution of the program to a certain step resulted in crontab terminating execution, I ran into the wrong database when I migrated the code. Causing the inability to access and died there.

Second, the implementation of environmental issues, when we encounter the first case, the general can be manually executed by the program to kill the problem in the cradle, in general, the master should not make the first mistake. The problem is that when we perform the manual execution successfully and the crontab cannot execute, the author encounters the problem of the execution environment, such as the setup problem of the related path. Solution: Execute source/home/user/.bash_profile at the front of the code

Thirdly, the system time is not correct. This problem is best understood, is also a more common and covert problem, solution: Date-s ********

The four is whether our script has executable permissions. You must ensure that the user executing the script has permission to perform the file change.

Five, the crontab daemon died. This is rarely the case, but it does not rule out that we can use it when we are unable to find other reasons. Solution: Restart the process.

Six, the problem that crontab does not carry on for a long time, the script writes is correct, but is not executed, the final solution is as follows:
Crontab-u Root/var/spool/cron/root
So the root user's crontab is in effect.
Service Crond Restart
Just restart the service.

VII, Crond did not start.

The script coding problem, script is written under window, to the Linux post-report "Nobelium?!" /bin/bash ", create a new shell script with the VI editor and save after entering the content.

Reference: http://blog.csdn.NET/zhangskd/article/details/6854589

http://my.oschina.Net/u/576757/blog/71084

Http://linux.vbird.org/linux_basic/0430cron.PHP about Anacron's article on Bird Brother

Http://study.chyangwa.com/IT/AIX/aixcmds1/crontab.htm

Setup of crontab timed tasks for Linux applications