In actual work, crontab may cause various problems. Below we will delve into the problems that are prone to occur in crontab in specific work and the methods to solve these problems.
crond is a daemon process used to perform tasks periodically or wait for certain events to be processed under Linux. It is similar to scheduled tasks under Windows. When the operating system is installed, this service tool will be installed by default and the crond process will be automatically started. The crond process regularly checks every minute whether there is a task to be executed, and if so, the task is automatically executed.
Task scheduling under Linux is divided into two categories: system task scheduling and user task scheduling.
crontab is very widely used in actual enterprise applications. Common uses include scheduled data backup, scheduled system detection, scheduled data collection, scheduled update of configuration, scheduled report generation, etc.
1. Crontab usage format
The commonly used formats of crontab are as follows:
crontab [-u user] [file] crontab [-u user] [-e|-l|-r |-i]
The options have the following meanings:
2. crontab file syntax
In the crontab file created by the user, each line represents a task, and each field in each line represents a setting. Its format is divided into six fields. The first five segments are time setting segments. The sixth segment is the command segment to be executed, the format is as follows:
minute hour day month week command
in:
“
? minute: represents the minute, which can be any integer from 0 to 59.
? hour: Indicates the hour, which can be any integer from 0 to 23.
? day: represents the date, which can be any integer from 1 to 31.
? month: Indicates the month, which can be any integer from 1 to 12.
? week: Indicates the day of the week, which can be any integer from 0 to 7, where 0 or 7 represents Sunday.
? command: The command to be executed can be a system command or a script file written by yourself.
”
In each of the above fields, you can also use the following special characters:
“
? 星号（）：代表所有可能的值，例如month字段如果是星号，则表示在满足其它字段的制约条件后每月都执行该命令操作。
? 逗号（,）：可以用逗号隔开的值指定一个列表范围，例如，“1,2,5,7,8,9”
? 中杠（-）：可以用整数之间的中杠表示一个整数范围，例如“2-6”表示“2,3,4,5,6”
? 正斜线（/）：可以用正斜线指定时间的间隔频率，例如“0-23/2”表示每两小时执行一次。同时正斜线可以和星号一起使用，例如/10，如果用在minute字段，表示每十分钟执行一次。
”
3、几个crontab例子
0 /3 /usr/local/apache2/apachectl restart
表示每隔3个小时重启apache服务一次。
30 3 6 /webdata/bin/backup.sh
表示每周六的3点30分执行/webdata/bin/backup.sh脚本的操作。
0 0 1,20 fsck /dev/sdb8
表示每个月的1号和20号检查/dev/sdb8磁盘设备。
10 5 /5 * echo "">/usr/local/apache2/log/access_log
表示每个月的5号、10号、15号、20号、25号、30号的5点10分执行清理apache日志操作。
在/etc目录下有一个crontab文件，这个就是系统任务调度的配置文件。
/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
从上面的示例文件可看出，crontab的任务列表主要由两部分组成：环境变量配置与定时任务配置。可能大家在工作中更多是只用到了任务配置部分。
前四行是用来配置crond任务运行的环境变量，第一行SHELL变量指定了系统要使用哪个shell，这里是bash，第二行PATH变量指定了系统执行命令的路径，第三行MAILTO变量指定了crond的任务执行信息将通过电子邮件发送给root用户，如果MAILTO变量的值为空，则表示不发送任务执行信息给用户，第四行的HOME变量指定了在执行命令或者脚本时使用的主目录。第六至九行就是crontab执行格式的具体写法。
通常在使用crontab添加任务时，我们会依靠自己已有知识编写定时语句。当需要测试语句是否正确时，还需要在服务器上不断调试，，这种方式太不高效了。有没有一款工具，只要我们给出语句，就能告诉具体执行时间以及对错呢？还真有，下面介绍一款老外开发的crontab在线解析工具。
工具地址：https://crontab.guru
给出这个工具的截图如下：
好用不好用，你试试就知道。
1、环境变量问题
当我们刚使用crontab时，运维老鸟们一般会告知所有命令尽量都使用绝对路径，以防错误。这是为什么？这就和我们下面要谈的环境变量有关了。
首先，获取shell终端环境变量，内容如下：
[root@SparkWorker1 dylogs]# env XDG_SESSION_ID=1629 HOSTNAME=SparkWorker1 TERM=linux SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=172.16.213.132 50080 22 HADOOP_PREFIX=/opt/hadoop/current CATALINA_BASE=/opt/hadoop/current/share/hadoop/httpfs/tomcat SSH_TTY=/dev/pts/1 QT_GRAPHICSSYSTEM_CHECKED=1 USER=root MAIL=/var/spool/mail/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/java/default/bin:/opt/hadoop/current/bin:/opt/hadoop/current/sbin:/root/bin PWD=/data/dylogs LANG=zh_CN.UTF-8 HOME=/root
要获取crontab环境变量信息，可以设置如下计划任务：
* * * * * /usr/bin/env > /tmp/env.txt
等待片刻，env.txt输出内容如下：
[root@SparkWorker1 dylogs]# cat /tmp/env.txt XDG_SESSION_ID=1729 SHELL=/bin/sh USER=root PATH=/usr/bin:/bin PWD=/root LANG=zh_CN.UTF-8 SHLVL=1 HOME=/root LOGNAME=root XDG_RUNTIME_DIR=/run/user/0 _=/usr/bin/env
从上面输出结果可知，shell命令行的PATH值为
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/java/default/bin:/opt/hadoop/current/bin:/opt/hadoop/current/sbin:/root/bin
而crontab中的PATH值为：
PATH=/usr/bin:/bin
对比crontab环境变量与shell终端环境变量的输出，可以发现两者的差异很大。大家可能遇到过，在shell命令行执行脚本都没有问题，而放到crontab后却执行异常，或者执行失败，此时，我们就需要考虑是否命令涉及的环境变量在crontab和shell命令行间存在差异。
例如，我们在crontab中执行了如下定时任务：
20 16 * * * php autosave.php
而如果我们的php是安装在/usr/local/bin/目录下的话，那么上面这个定时任务由于无法找到php命令，会运行失败。
那么，知道了环境变量问题，可能导致计划任务无法正常执行，怎么才能避免这个问题呢，这个交给大家一个终极大招，可以在crontab中加入如下配置，保证你的计划任务执行不会出现环境变量问题：
* * * * * source /$HOME/.bash_profile && command
这个其实是在执行计划任务命令之前，先加载了用户环境变量信息，由此可保证所有环境变量都可正常加载。
2、定时时间配置误区
时间是crontab的核心，稍微配置不当，就会出现问题，先看在整点时间设置时可能出现的错误，例如，设定每天2点执行一次任务，很多朋友可能这么写过：
* 2 * * * command
很明显，这个时间写法是错误的，当我们听到每天2点执行一次某任务时，很多人会把重点放在2点，而忽略了执行一次的需求。上面这个定时任务他会在2点开始执行，每分钟执行一次，总共执行60次。
正确的写法应该是这样的：
0 2 * * * command
这个才表示每天2点0分执行command对应的任务。
3、特殊符号%问题
%在crontab中是特殊符号，具体含义如下：
第一个%表示标准输入的开始，其余%表示换行符，看下面两个例子：
* * * * * cat >> /tmp/cat.txt 2>&1 % stdin out
查看/tmp/cat.txt的内容为：
stdin out
再看下面这个例子：
* * * * * cat >> /tmp/cat1.txt 2>&1 % stdin out 1 % stdin out 2 % stdin out 3
查看 /tmp/cat1.txt的内容如下：
stdin out 1 stdin out 2 stdin out 3
有输出内容可知，第一个%表示标准输入的开始，其余%表示换行符。
既然”%”是特殊字符,那么在crontab中使用时，就要特别注意，怎么使用这些特殊字符呢，很明显，使用转移字符即可，例如：
* * * * * cat >> /tmp/cat2.txt 2>&1 % Special character escape \%.
查看输出/tmp/cat2.txt 输出内容如下：
Special character escape %.
可以看到，执行成功了，并成功避开这个坑了。
4、关于crontab的输出重定向
在crontab执行的计划任务中，有些任务如果不做输出重定向，那么原本会输出到屏幕的信息，会以邮件的形式输出到某个文件中，例如，执行下面这个计划任务：
* * * * * /bin/date
这个计划任务是没有做输出重定向的，他的主要用途是输出时间，由于没有配置输出重定向，那么这个时间信息默认将以邮件的形式输出到/var/spool/mail/$USER（这个$USER对应的是系统用户，这里是root用户）文件中，大致内容如下：
From root@SparkWorker1.localdomain Fri Sep 21 12:58:02 2022 Return-Path: X-Original-To: root Delivered-To: root@SparkWorker1.localdomain Received: by SparkWorker1.localdomain (Postfix, from userid 0) id F2745192AE; Fri, 21 Sep 2022 12:58:01 +0800 (CST) From: "(Cron Daemon)" To: root@SparkWorker1.localdomain Subject: Cron /bin/date Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated Precedence: bulk X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Message-Id: Date: Fri, 21 Sep 2022 12:58:01 +0800 (CST) 2022年 09月 21日 星期五 12:58:01 CST
由此可见，输出内容还是很多的，如遇到任务有大量输出的话，会占用大量磁盘空间，显然，这个邮件输出最好关闭，怎么关闭呢，只需设置MAILTO环境变量为空即可，上面的计划任务，可做如下修改：
MAILTO="" * * * * * /bin/date
这样，就不会发邮件信息到/var/spool/mail/$USER下了，但是问题并没有彻底解决，关闭mail功能后，输出内容将继续写入到/var/spool/clientmqueue中，长期下去，可能占满分区的inode资源，导致任务无法执行。
为了避免此类问题发生，建议任务都加上输出重定向，例如，可以在crontab文件中设置如下形式，忽略日志输出：
0 */3 * * * /usr/local/apache2/apachectl restart >/dev/null 2>&1
其中，“/dev/null 2>&1”表示先将标准输出重定向到/dev/null，然后将标准错误重定向到标准输出，由于标准输出已经重定向到了/dev/null，因此标准错误也会重定向到/dev/null，这样日志输出问题就解决了。
5、调试crontab问题的一般思路
要解决crontab相关异常问题，可按照如下思路进行调试：
（1）、通过/var/log/cron日志确认任务是否执行
（2）、如未执行则分析定时语句，是否是环境变量问题、特殊字符问题、时间配置问题、权限问题等。
（3）、确认crond服务开启，如果定时语句也正确，检查crond服务是否开启。
Systemd方式(centos7及以上)
[root@SparkWorker1 spool]# systemctl status crond.service
SysVinit方式(centos7以下)
[root@SparkWorker1 spool]# service crond status
（4）确认定时任务中命令是否执行成功
这个问题可通过输出获取错误信息进行调试，方法就是利用重定向获取输出，然后进行分析。举例如下：
* * * * * python /usr/local/dyserver/dypos.py >> /tmp/dypos.log 2>&1
通过加上“/tmp/dypos.log 2>&1”，就可以很快定位问题，因为这个dypos.py脚本在执行的时候会把错误信息都输出到dypos.log 中，接着查看dypos.log文件，问题一目了然：
[root@SparkWorker1 spool]# cat /tmp/dypos.log /bin/sh: python: 未找到命令 /bin/sh: python: 未找到命令
显示python命令没有找到，很明显的就可以确定是环境变量的问题。这种方式定位问题非常有效。
The above is the detailed content of What you don't know about crontab under Linux. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
