Linux服务器定时任务主要通过crontab实现，它能精确控制任务在指定时间自动执行，是运维自动化的基石。 无论是日志清理、数据备份还是系统监控，定时任务都承担着幕后操盘手的角色，掌握crontab的用法，能让你的服务器从“被动响应”变成“主动服务”，省下大量重复劳动。
Linux crontab 命令详解：掌握定时任务核心用法
crontab是Linux下最普及的定时任务工具,几乎没有之一，它的配置文件叫crontab文件，每个用户都可以拥有自己的crontab，系统级别的任务则放在/etc/crontab里，无论你是运维新人还是老手，理解crontab的语法和命令都是基本功。
crontab基本语法与时间格式
crontab的每一行定义一个任务,格式如下：
分 时 日 月 周 命令五个时间字段按顺序表示：分钟（0-59）、小时（0-23）、日期（1-31）、月份（1-12）、星期（0-7，0和7都代表周日），每个字段可以用星号（）表示“任意值”，用逗号分隔多个值，用减号表示范围，用斜杠表示步长。
举个例子：
0 3 /usr/bin/backup.sh表示每天凌晨3点执行备份脚本。/5 /usr/local/bin/check_health表示每5分钟检查一次服务状态。0 9-17 1-5 /opt/scripts/report.py表示工作日的工作时间（9点至17点）每小时执行一次报告。
时间格式是crontab的精髓,也是出错高发区，行业共识认为，超过半数的crontab故障都是因为时间写错了，比如把分钟和小时写反，或者忽略了星期和日期的互斥关系。
crontab常用命令选项
crontab工具本身提供几个关键命令,用来管理当前用户的定时任务列表：
- crontab -e：编辑当前用户的crontab文件，如果不存在则新建，编辑器默认是vi，可以通过环境变量EDITOR修改。
- crontab -l：列出当前用户的所有定时任务。
- crontab -r：删除当前用户的crontab文件，慎用。
- crontab -u：指定用户，只有root能用。
crontab -u www -e编辑www用户的定时任务。
这些命令是日常操作频率最高的,熟练掌握能避免很多低级错误。
编辑与查看定时任务
编辑crontab时,强烈建议先在命令行里调试好脚本，再放入crontab，因为crontab默认不加载用户的环境变量，很多脚本在终端里跑没问题，放进crontab后却报错，多数情况下是因为PATH和家目录的问题。
每次修改crontab后,可以用 crontab -l 确认内容是否生效，如果想查看系统级任务，直接看 /etc/crontab 和 /etc/cron.d/ 目录下的文件。
crontab 定时任务 不执行？这样排查准没错
crontab定时任务不执行是运维里最常遇到的难题之一,脚本明明手动能跑，放进crontab就跟死了一样，其实原因就那么几个，按顺序排查，多数情况下几分钟就能定位。
环境变量问题：为什么脚本手动能跑，crontab不行
crontab执行任务时,shell环境非常精简，PATH通常只有 /usr/bin:/bin，如果你的脚本里用到了其他目录下的命令，/usr/local/bin 下的工具，或者脚本里依赖了自定义的变量，就会执行失败。
业内专家指出,相当一部分crontab不执行故障都和环境变量有关，解决办法：在脚本开头显式加载环境变量，source /etc/profile 或 source ~/.bashrc，或者在crontab命令里直接写绝对路径，也可以用 env 命令对比crontab环境和手动执行环境的差异。
路径问题：使用绝对路径避免踩坑
crontab的当前工作目录通常是用户的家目录,但不一定，如果你的脚本里用了相对路径来读写文件，./log/backup.log，很可能找不到目录。最稳妥的做法是脚本里所有路径都写绝对路径，包括脚本自身调用的其他文件路径。
crontab命令里的执行体也建议用绝对路径,/usr/bin/php /var/www/cron/update.php 而不是 php update.php。
权限问题：确保脚本和命令可执行
脚本必须要有执行权限（chmod +x），同时crontab用户要有权读取脚本和执行目录，如果脚本里调用了需要sudo的命令，要么在crontab里用 sudo（需要配置NOPASSWD），要么把脚本加入root的crontab里，还有一种情况是脚本写的文件权限不对，导致后续任务失败，可以用 umask 控制默认权限。
查看日志：定位问题的关键
crontab的执行日志通常写在系统日志里,根据发行版不同，位置可能不同：
- 大多数Linux（CentOS、Ubuntu等）：查看
/var/log/cron或journalctl -u crond。 - 日志里会记录每次任务执行的时间和命令,如果执行失败，通常会有错误原因，command not found”或“exit status 1”。
如果日志里根本没有记录,说明crontab服务可能没启动，检查 systemctl status crond 或 service cron status，如果日志里显示了执行但没报错，任务却没生效，那多半是脚本本身的问题，建议在脚本里重定向输出到文件，30 2 /usr/local/bin/backup.sh >> /tmp/backup.log 2>&1，把标准输出和错误输出都保存下来，方便分析。
Linux 服务器定时任务 备份脚本编写指南
备份是定时任务最常见的应用场景之一,一个合格的自动备份脚本，不仅要能正确备份，还要考虑日志、保留策略和异常处理。
备份脚本核心要素
一个典型的备份脚本包含以下内容：
- 定义变量：备份源目录、目标目录、时间戳、保留天数等。
- 创建备份文件：通常是tar打包，或者用rsync同步。
- 判断备份是否成功：通过检查退出码或文件大小。
- 清理旧备份：根据保留策略删除过期的备份文件。
- 记录日志：将执行结果写入日志文件，方便日后查阅。
一个简单的数据库备份脚本片段：
#!/bin/bash
BACKUP_DIR=/data/backups
DATE=$(date +%Y%m%d%H%M)
mysqldump -u root mydb | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz
if [ $? -eq 0 ]; then
echo "$DATE: backup success" >> /var/log/mysql_backup.log
else
echo "$DATE: backup failed" >> /var/log/mysql_backup.log
fi
find $BACKUP_DIR -type f -name ".sql.gz" -mtime +7 -delete将备份脚本加入crontab
脚本写好并测试通过后,在crontab里添加一行，
0 2 /usr/local/bin/db_backup.sh建议把脚本放在 /usr/local/bin 或 /opt/scripts 目录下，并确保执行权限正确，如果脚本需要特定环境变量，在脚本开头 source 一下。
日志与告警配置
备份虽然重要,但没人天天盯着日志，可以配置crontab任务在失败时发送邮件，crontab默认会通过本地的邮件系统（如sendmail或postfix）把未捕获的输出发送给用户，但很多服务器没有配邮件，更实用的做法是：在脚本里判断失败时，调用外部告警接口，比如发送钉钉消息、短信或写入监控系统，也可以把备份日志汇总到集中日志平台，方便排查。
crontab vs systemd timer：如何选择定时任务工具
近年来,systemd timer 逐渐成为 cron 的替代方案，两者的对比一直是运维圈的热门话题，不少人在选择 Linux 定时任务设置方法时犹豫不决，下面从几个维度对比，帮你做决定。
| 对比维度 | crontab | systemd timer |
|---|---|---|
| 配置复杂度 | 简单，一行一个任务 | 需要写两个文件（service + timer） |
| 依赖管理 | 不支持 | 支持等待网络、其他服务就绪 |
| 日志管理 | 写在系统日志或自定义 | 统一用 journalctl，结构化 |
| 精度 | 分钟级 | 支持秒级和实时触发 |
| 随机延迟 | 不支持 | 支持 RandomizedDelaySec |
| 资源占用 | 极低 | 稍高，但可忽略 |
| 适用场景 | 传统运维，简单任务 | 复杂依赖，需要精确控制的场景 |
crontab的优势与局限
crontab最大的优势是简单和通用,几乎所有的Linux发行版都预装了cron，配置格式一目了然，社区资料丰富，对于大多数运维场景，比如定时清理日志、运行脚本，crontab完全够用，局限在于它不关心任务依赖，也不支持秒级调度，如果前一个任务没跑完，下一个任务到点还是照常启动，容易造成资源冲突。
systemd timer的特点
systemd timer 是 systemd 家族的一员，适合与现代系统深度集成，它可以设置任务在特定条件满足后执行，网络就绪后”“服务启动后”，也可以用 OnCalendar 实现类似crontab的定时，精度更高，timer 还支持 RandomizedDelaySec 来避免任务扎堆，对于大规模集群的定时任务非常有用。
选择建议：根据场景决定
如果你的服务器是传统的 CentOS 7 或 Ubuntu 18，crontab 依然是主流选择，如果服务器已经以 systemd 为核心，并且任务需要依赖其他服务，或者需要更精细的控制，可以考虑 systemd timer，行业共识认为，在可预见的未来，crontab 不会消失，但 systemd timer 的使用比例会逐渐上升，对于新项目，可以优先考虑 systemd timer。
Linux定时任务常见问题与解答
crontab定时任务不执行，但日志里没有错误信息，怎么办？
这种情况通常是因为crontab任务的输出没有被捕获,或者脚本本身“静默失败”，先检查crontab命令是否被正确解析，可以在任务里加上触目可见的副作用，比如创建一个文件，然后检查脚本的退出码，在脚本末尾加上 exit 0 确保返回正确，把标准输出和错误输出都重定向到日志文件，重新执行一次，看日志里到底发生了什么。
如何查看crontab日志？
crontab的日志位置因发行版而异,在大多数系统中，可以查看 /var/log/cron 文件，或者使用 journalctl -u crond（如果cron绑定到systemd），日志里会记录每一条任务的执行时间、命令以及退出状态，如果日志里没有记录，说明cron服务可能没有运行，或者权限不足导致无法记录，可以通过 systemctl status crond 确认服务状态。
crontab和at命令有什么区别？
crontab用于周期性执行的定时任务,而at命令用于一次性任务，明天下午3点执行一次”，at命令操作简单，但触发后不会自动重复，crontab则适合需要长期按计划运行的场景，比如每天凌晨备份，两者互补，运维中常根据需求选择。