Use the linux command crontab to execute other commands at intervals

1.1 / etc/crontab files

There is an crontab file in the /etc directory, where some schedulers are running on the system. Each user can establish their own schedule crontab.

Such as:

[root@dave ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

1.2 /etc/ cron.deny and /etc/ cron.allow

/etc/cron.deny  Not available crontab  User of command 
/etc/cron.allow  Means that it can be used crontab To the user. 

If both files exist, /etc/ cron.allow takes precedence. If neither file exists, only the superuser can schedule the job.

Each user generates one of their own crontab files. These files are in the /var/spool/cron directory, such as:

[root@dave ~]# cd /var/spool/cron
[root@dave cron]# ls
oracle  root

Let's look directly at this file, the contents of which correspond to the crontab-l 1 displayed by the corresponding user.

[root@dave cron]# cat oracle
00 6 * * * /u02/scripts/del_st_archive.sh >/u02/scripts/del_st_arch.log 2>&1
[root@dave cron]# cat root
0 12 * * * /root/bin/sync-clock.sh
[root@dave cron]#

2. Instructions for   Crontab

2.1   Crontab syntax

usage:  crontab [-u user] file
crontab [-u user] [ -e | -l | -r ]

  -e           (edit user's crontab)

  -l           (list user's crontab)

  -r           (delete user's crontab)

  -i           (prompt before deleting user's crontab)

  -s           (selinux context)

Where file is the name of the command file. If the file is specified on the command line, execute the crontab command and copy the file to the crontabs directory. If the file is not specified on the command line, the crontab command takes the commands typed on standard input (the keyboard) and stores them in the crontab directory as well.

Help:

[root@dave ~]# man crontab
CRONTAB(1)  CRONTAB(1)
NAME
crontab - maintain crontab files for individual users (ISC Cron V4.1)
SYNOPSIS
crontab [-u user] file
crontab [-u user] [-l | -r | -e] [-i] [-s]

OPTIONS

-u         It   specifies   the name of the user whose crontab is to be tweaked.   If this   option is not given, crontab examines "your" crontab, i.e., the crontab   of the   person   executing the command.   Note that su(8) can confuse crontab and that if you are running inside of su(8) you should always use the -u   option for   safety¡¯s sake.   The first form of this command is used to install a new crontab from some named file or standard input if the pseudo-filename "-" is given.

-l         The current crontab will be displayed on standard output.

-r         The current crontab will be be removed.

-e         This   option   is used to edit the current crontab using the editor specified by the VISUAL or EDITOR environment variables.   After you exit from the edi-tor, the modified crontab will be installed automatically.

-i         This   option   modifies the -r option to prompt the user for a ¡¯y/Y¡¯ response before actually removing the crontab.

-s         It will append the current SELinux security context string as   an   MLS_LEVEL setting   to   the   crontab file before editing / replacement occurs - see the documentation of MLS_LEVEL in crontab(5).

SEE ALSO
crontab(5), cron(8)
FILES
/etc/cron.allow
/etc/cron.deny
STANDARDS
The crontab command conforms to IEEE Std1003.2-1992 (¡®¡®POSIX¡¯¡¯).  This new  command syntax  differs  from  previous versions of Vixie Cron, as well as from the classic
SVR3 syntax.
DIAGNOSTICS
A fairly informative usage message appears if you run it with a bad command line.
AUTHOR
Paul Vixie <vixie@isc.org>
4th Berkeley Distribution16 Januar 2007 CRONTAB(1)

2.2   Crontab format description

We can add commands to execute with crontab-e. The result of the command execution, whether standard output or error output, will be emailed to the user.

The added command must be in the following format:

* * * * * /command path
The first five fields can take an integer value and specify when to start working, and the sixth field is a string, or command field, which includes the commands that crontab schedules to execute. The fields are separated by spaces and tabs.

The first five fields represent:

Min: 0-59

Hr: 1-23

Date: 1 to 31

Month: 1-12

Week: 0-6 (0 for Sunday)

You can also use 1 for some special symbols:

* : represents any time

, : represents segmentation

- : represents a segment, as in the second end: 1-5, represents 1 to 5 points

/n: means that each unit of n is executed once. For example, in paragraph 2, */1 means that the command is executed once every 1 hour. Or we could write it as 1 minus 23/1.

1 some examples:

00 8,12,16 * * * /data/app/scripts/monitor/df.sh
30 2 * * * /data/app/scripts/hotbackup/hot_database_backup.sh
10 8,12,16 * * * /data/app/scripts/monitor/check_ind_unusable.sh
10 8,12,16 * * * /data/app/scripts/monitor/check_maxfilesize.sh
10 8,12,16 * * * /data/app/scripts/monitor/check_objectsize.sh

43 21 * * * 21:43  perform 
15 05 * * * 　　 05:15  perform 
0 17 * * * 17:00  perform 

2.3   & background execution

When a job runs in the foreground, the terminal is occupied by the job. When a job runs in the background, it doesn't occupy the terminal. You can use the &command to put jobs in the background.

Such as:

30 2 * * * /data/app/scripts/hotbackup/hot_database_backup.sh &

Be careful when running jobs in the background: commands that require user interaction should not be executed in the background because your machine will be waiting around.

However, a job running in the background will output the results to the screen, interfering with your work. If a job running in the background produces a lot of output, it is best to redirect its output to a file using the following methods:

Such as:

command >out.file 2>&1 &

In this case, 2 > &1 means that all standard and error output will be redirected to a file called out.file.

2.4   2 > & 1 meaning

Here's an example:

0 2 * * * /u01/test.sh >/dev/null 2>&1 &

This means executing the command in the background, redirecting error output 2 to standard output 1, and then putting all standard output 1 into the /dev/null file.

Here are a few Numbers:

0 is for keyboard input

1 is standard output

2 represents error output.

We could also write:

0 2 * * * /u01/test.sh  >/u01/out.file &  -- It's not there, it's default 1
0 2 * * * /u01/test.sh  1>/u01/out.file &
0 2 * * * /u01/test.sh  2>/u01/out.file &
0 2 * * * /u01/test.sh  2>/u01/out.file  2>&1 &

Redirect the tesh.sh command output to out.file, that is, the output is not printed to the screen, but to the out.file file.

2 > &1 is to redirect the error output to standard output. Then redirect standard input to the file out.file.

Ampersand is the file description 1, which is the standard output, and if there's a minus ampersand, which is the number 1, which is the redirection to file 1.

& : background execution

Testing:

ls 2>1  :   No. No. 2 Error in file, but output 1 An empty file 1 ; 
ls xxx 2>1 :   There is no xxx The error in this file is output 1 ; 
ls xxx 2>&1 :   Will not generate 1 This file is gone, but the error went to standard output; 
ls xxx >out.txt 2>&1 == ls xxx 1>out.txt 2>&1 ;    Because of the redirection notation > The default is 1 ", which transmits both the error output and the standard output out.txt  File. 

2.5   2 > The reason why I put the &1 in the back

Format: command > file 2 > &1     == command   1 > file 2 > &1

The first is command > file redirects standard output to file, 2 > &1 is the standard error that copies the standard output, which is also redirected to file, and the end result is that both the standard output and the error are redirected to file.

If changed to: command 2 > &1 > file

2 > The standard error copies the behavior of the standard output, but the standard output is still in the terminal. > The output is redirected to file after file, but the standard error remains at the terminal.