Shell from the basics: Chapter 3 background command execution

Article title: Shell from the basics: Chapter 3 run commands in the background. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Author:
Sorting: lanlingsheng
　　
When you work on a terminal or console, you may not want to occupy the screen by running a job, because there may be more important things to do, such as reading emails. For intensive disk access processes, you may want them to run during off-peak hours every day. To enable these processes to run in the background, that is, they do not run on the terminal screen, there are several options available.
In this chapter, we will discuss:
• Set the crontab file and use it to submit a job.
• Use the at command to submit a job.
• Submit a job in the background.
• Use the nohup command to submit a job.
Glossary:
Cron system scheduling process. It can be used to run jobs during off-peak hours every day, or during different periods of one week or one month.
At command. It is used to run some special jobs at a specific time, or in a later non-load peak or peak load period.
& Use it to run a process that takes a short time in the background.
Nohup uses it to run a command in the background, even if the user exits, it will not be affected.
3.1 cron and crontab
Cron is the main scheduling process of the system. it can run jobs without human intervention. There is
The crontab command allows you to submit, edit, or delete a job. Each user can have a crontab file.
To save the scheduling information. It can be used to run any shell script or command, once an hour, or once a week.
Three times, depending on you. Every user can have their own crontab file, but in a large system,
System administrators usually disable these files, but only keep one of them in the system. The system administrator
Cron. deny and cron. allow files to prohibit or allow users to own crontab files.
3.1.1 crontab field
To run a job at a specific time, you need to understand the meaning and format of each field in each entry of the crontab file. These domains are as follows:
1st columns Minute 1 ~ 5 9
2nd columns hour 1 ~ 2 3 (0 indicates midnight)
1-3rd ~ 3 1
4th columns month 1 ~ 1 2
5th columns in a week 0 ~ 6 (0 indicates Sunday)
6th columns of commands to run
The following is the crontab format:
Minute <> Hour <> day <> month <> Week <> command to run
<> Indicates a space.
An entry in the Crontab file is read from the left. The first column is the minute, and the last column is the command to be run. It is located after the week.
In these domains, you can use a horizontal bar to indicate a time range. for example, if you want to run a job from Monday to Friday, you can use 1-5 in the weekly domain. You can also use commas (,) in these domains. for example, if you want to run a job on Monday or Thursday, you only need to use 1, 4. The asterisk (*) can be used to represent consecutive time periods. If you do not have a special limit on a time domain, you should also enter * in this domain *. Each entry in the file must contain five time fields, and each field must be separated by a space. All the comment lines in this file must be expressed as # at the beginning of the line.
3.1.2 crontab entry example
Here are some examples of crontab file entries:
30 21 ***/apps/bin/cleanup. sh
The preceding example shows cleanup. sh in the/apps/bin directory at every night.
45 4, 10, 22 **/apps/bin/backup. sh
The preceding example indicates the backup. sh in the/apps/bin directory of the 4: 4 5 running on the 1, 1, 0, and 2 every month.
10 1 ** 6, 0/bin/find-name "core"-exec rm {}\;
The preceding example shows that a find command is run every Saturday and Sunday.
0, 30 18-23 ***/apps/bin/dbcheck. sh
The preceding example shows running dbcheck. sh in the/apps/bin directory every 30 minutes between and every day.
0 23 ** 6/apps/bin/qtrend. sh
The preceding example shows qtrend. sh in the/apps/bin directory run at every Saturday.
You may have noticed that in the above example, each command provides an absolute path. When you use crontab to run a shell script, you must give the absolute path of the script and set the corresponding environment variables. Remember, since the user submitted these jobs to cron, it is necessary to provide cron with all the required environments. Do not assume that cron knows the required special environment. Therefore, make sure that all necessary paths and environment variables are provided in the shell script, except for some automatically set global variables.
If cron cannot run the script, you will receive an email explaining the cause.
3.1.3 crontab command options
The crontab command is generally used as follows:
Crontab [-u user]-e-l-r
Where:
-U user name.
-E: Edit the crontab file.
-L list the content in the crontab file.
-R: delete the crontab file.
If you log on with your own name, you do not need to use the-u option, because the current user can be known when executing the crontab command.
3.1.4 create a new crontab file
Before submitting a crontab file to the cron process, you must set the environment variable EDITOR. The cron process determines which editor to use to edit the crontab file. 99% of UNIX and LINUX users use vi. if so, edit the. profile file in the $ HOME directory and add the following line to it:
EDITOR = vi; export EDITOR
Save and exit.
Create Cron file, where Is the user name, for example, dave cron. In this file
Add the following content.
# (Put your own initials here) echo the date to the console every
#15 minutes between 6 and 6 am
0, 15, 30, 45 18-06 ***/bin/echo 'date'>/dev/console
Save and exit. Make sure that the first five fields are separated by spaces.
In the preceding example, the system outputs the current time to the console every 5 minutes. If the system crashes or hangs, you can see at the last displayed time when the system stops working. In some systems, tty1 is used to represent the console. you can modify the preceding example based on the actual situation.
To submit the crontab file you just created, you can use the newly created file as a parameter of the cron command:
$ Crontab davecron
Now the file has been submitted to the cron process and will run every 5 minutes.
At the same time, a copy of the new file has been stored in the/var/spool/cron directory, and the file name is the user name (dave ).
3.1.5 List crontab files
To list crontab files, you can use:
$ Crontab-l
# (Crondave installed on Tue May 4 13:07:43 1999)
# DT: echo the date to the console every 30 minutes
0, 15, 30, 45 18-06 ***/bin/echo 'date'>/dev/tty1
　　
　　
You will see something similar to the above. You can use this method to back up the crontab file in the $ h o m e Directory:
$ Crontab-l> $ HOME/mycron
In this way, once the crontab file is accidentally deleted, you can use the method described in the previous section to quickly restore it.
3.1.6 edit the crontab file
If you want to add, delete, or edit entries in the crontab file, and set the EDITOR environment variable to vi, you can use vi to edit the crontab file. the corresponding command is:
$ Crontab-e
You can modify the crontab file and exit as you can edit any other file using v I. If some entries are modified or new entries are added, cron will perform necessary integrity checks when saving the file. If a field contains a value out of the permitted range, it will prompt you.
We may add new entries when editing the crontab file. For example, add the following one:
# DT: delete core files, at 3.30am on 1, 7, 14,21, 26 days of each month
30 3, 26 **/bin/find-name "core"-exec rm {}\;
Save and exit now. It is best to add a comment to each entry in the crontab file so that you can know its function and running time. More importantly, you can know which user's job this is.
Now let's use the previous crontab-l command to list all its information:
$ Corntab-l
# (Crondave installed on Tue May 4 13:07:43 1999)
# DT: echo the date to the console every 30 minutes
0, 15, 30, 45 18-06 ***/bin/echo 'date'>/dev/tty1
# DT: delete core files, at 3.30am on 1, 7, 14,21, 26 days of each month
30 3, 26 **/bin/find-name "core"-exec rm {}\;
　　
3.1.7 delete the crontab file
To delete the crontab file, you can use:
$ Crontab-r
3.1.8 restore the lost crontab file
If you accidentally delete the crontab file by mistake, if you have a backup in your $ h o m e directory, you can copy it to/var/spool/cron/ , Where Is the user name. If the copy cannot be completed due to permission issues, you can use:
$ Crontab
<File name> indicates the file name of the copy in the $ HOME directory.
We recommend that you save a copy of the file in your $ HOME directory. I have had a similar experience and deleted the crontab file several times by mistake (because the r Key is next to the right of the e key .). This is why it is recommended that you do not directly edit the crontab file in some system documents, but edit a copy of the file and resubmit the new file.
Some crontab variants are somewhat weird, so be careful when using the crontab command. If you omit any options, crontab may open an empty file or it looks like an empty file. Press delete to exit. do not press <Ctrl-D>. Otherwise, the crontab file will be lost.
3.2 at Command
The at command allows you to submit a job to the cron daemon to run the job later. The later time may be 1 0 min later or several days later. If you want to run it after one month or longer, you 'd better use the crontab file.
Once a job is submitted, the at command retains all the current environment variables, including the path. Unlike crontab, it only provides the default environment. All outputs of the job will be sent to the user by email. unless you have redirected the output, most of the time it is redirected to a file.
Like crontab, the root user can control which users can use the at. allow and at. deny files in the/etc directory.
　　
Which users cannot use the at command. However, the use of at commands is not as strict as that of crontab.
The basic form of the at command is:
At [-f script] [-m-l-r] [time] [da