企业官网建设流程全解析

我先讲个很典型的场景：你写了个脚本，手动执行一切正常，于是高高兴兴把它加进了 crontab，设成每天早上 3 点跑。第二天上班一看，任务压根没执行。你反复检查语法、检查路径，全对，但它就是不跑。最后偶然发现，原来是脚本里用了一个自定义的环境变量，而在 cron 的上下文里根本不存在。

这种问题，几乎每一个碰过 Linux 计划任务的人都会遇到。很多初学者把 cron 想得太简单，觉得“设个时间、写条命令”就完事了。但实际用下来，这里面的门道比你想象的多得多。包括时间表达式的坑、环境变量的坑、日志排查的坑，还有——更关键的——当 cron 满足不了需求时，你还有其他工具能顶上。

这篇我会围绕 Linux 计划任务（主要是 cron，也会提 anacron、systemd timer 和 at）写清楚三件事：它是怎么工作的、配置时最容易踩哪些坑、以及任务不执行时怎么一步步排查。无论你是刚接触 Linux 的运维新手，还是写过 crontab 但被坑过几次的老手，这篇文章都能给你一点平时文档里看不到的经验。

1. 先从“为什么需要计划任务”说起：手动运维的无力感

很多刚入门的朋友会问，计划任务到底解决什么问题？我打个比方：如果你的机器是一个24小时营业的便利店，那你自己不可能每分每秒守在那里，你得雇一个守夜人，让他按照你写在纸条上的清单，在特定的时间点去做特定的事——开店门、关灯、补货。在 Linux 世界里，这个守夜人的角色就是cron（准确说是crond守护进程），你写的纸条就是 crontab 配置文件。

没有计划任务的日子我是真实经历过的。以前我刚管理服务器的时候，每天手工跑备份脚本，偶尔忘记跑就得过后补；日志文件涨到几个 GB 才想起来清理；证书快过期了也总靠别人提醒。后来把所有重复性的运维操作全部塞进计划任务，才真正从“人肉提醒”里解放出来。

那 Linux 下的计划任务都有哪些选择？最经典的当然是 cron 家族。再细化一点，常见的有这么几类：

• vixie-cron / cronie：大多数发行版默认安装的传统 cron 实现。
• anacron：适合不是 7×24 小时开机的机器，比如你的笔记本。它不要求系统在指定时间点一定是开着的，只要开机后补跑就行。
• systemd timer：如果你用 systemd 系发行版（现在绝大多数都是），它可以完全替代 cron，而且功能更强。
• at：一次性任务，比如“5点后帮我重启一下服务”，用完即走，不重复。

其中 cron 和 crontab 的使用场景最广泛，网上资料也最多。但恰恰因为它普及，大家的理解误区反而更多。老话说得好，越是常用的东西，越值得把它彻底吃透。

2. crontab 的书写规范：五个时间字段，一个字符都不能错

先看最核心的部分：crontab 到底怎么写。配置文件的每一行代表一个任务，基本格式长这样：

* * * * * command_to_execute

前五个字段是时间，分别代表：分、时、日、月、星期。注意这个顺序，是 分-时-日-月-星期，不是 时-分-日-月-星期，我见过太多人第一次写的时候把前两个字段搞反，导致任务在一个完全不对的时间点执行。

为了更清楚地展示，我把每个字段的取值范围和含义列在下面：

除了直接填数字，还有几个特殊符号要熟练运用：

• *：代表任意值，也就是“每分/每小时/每天”的意思。
• ,：列举多个值。例如1,15,30 * * * *表示每小时的第1、15、30分钟各执行一次。
• -：连续范围。例如9-18 * * * *表示每天9点到18点的每一分钟都执行。
• /：步长。例如*/10 * * * *表示每10分钟执行一次。注意*/10是“从0开始，每隔10个时间单位”，不是“在任意10的倍数分钟”。

这里我不厌其烦地强调一个细节：第5字段（星期）的取值范围是 0-7，0 和 7 都是周日。很多人只知道 0-6，结果用 7 表示周日的时候在一些旧的 cron 实现上会有兼容问题，虽然现在主流实现都支持，但为了保险，建议只用 0-6。

接下来是实操示例，直接抄作业就行：

# 每天早上 6 点执行备份脚本 0 6 * * * /usr/local/bin/backup.sh # 每 5 分钟拉一次最新库存数据 */5 * * * * /opt/scripts/sync_inventory.py # 每周一、周三、周五的凌晨 2 点清理临时文件 0 2 * * 1,3,5 /usr/local/bin/cleanup_tmp.sh # 每个月 1 号和 15 号的中午 12 点生成统计报表 0 12 1,15 * * /usr/local/bin/report.sh # 每年 6 月 1 日的零点执行年度归档 0 0 1 6 * /usr/local/bin/archive_yearly.sh

在真正执行之前，我强烈建议你先把整行内容放到一个临时文件里，用crontab命令去加载，而不是直接在线上环境反复试错。因为你永远不知道一个手误会产生什么后果——比如本想每 5 分钟跑一次，结果因为字段写错变成了每 5 秒跑一次（虽然 classic cron 最小粒度是分钟，但某些 vixie-cron 的变种对星期和日期的交叉逻辑处理得很奇怪，抱怨出错的人不在少数）。

关于日期字段和星期字段同时设置时的语义，这里有个很多人误解的点：当第3字段（日）和第5字段（星期）都被设置成非*时，这两个条件是“或”的关系，而不是“与”的关系。也就是说，0 0 1 * 2的意思是“每月1号执行，且每周二执行”，即两者满足其一就会执行，而不是“1号且同时是周二”才执行。这个特性和绝大多数人的直觉相反，我第一次知道这个坑的时候也是相当震惊，后来查了 POSIX 标准才确认。如果你的需求真的是“某月的某天且恰好是某种星期”才执行，那建议在脚本内部用 date 命令做二次判断。

3. 为什么 cron 任务会“慢半拍”？底层机制比你想象得简单也更笨

很多人用 cron 的时候都在问：它到底是什么时候触发任务的？答案是——每一分钟。

crond 守护进程启动后，会在每分钟的开始时刻读取 crontab 文件（准确说是读取之后比较文件是否更新过），然后判断这一分钟需要执行哪些任务。也就是说，cron 的最小调度粒度就是1 分钟。如果你写了一个* * * * *的任务，它会在每一分钟的第一秒被执行，不会有毫秒级的精确触发。

这个事情带来两个后果：

第一，你没法用 cron 精确实现“每 30 秒跑一次”这种需求。网上经常有人问这类问题，网上的答案也很统一：cron 做不到，请换其他工具。如果非要实现，可以用两个 crontab 行错开 30 秒，例如：

* * * * * command_A * * * * * sleep 30 && command_A

但我不推荐把这种 hack 用到生产环境，原因很简单：第一个任务如果在某分钟执行耗时超过 30 秒，两个实例就可能重叠。更合理的做法是使用 systemd timer 加OnUnitActiveSec=30s，或者直接在脚本内部自己加循环，比如你用 nohup 起了个常驻进程，让它在 while 循环里 sleep 30 秒。

第二，crond 并不保证任务执行时间的绝对精确。如果你在系统负载非常高的时候设置了一个精确到分钟的定时任务，任务可能会延迟几秒甚至几十秒才开始执行。对于绝大多数运维场景，这种误差完全可接受；但对某些对时间敏感的任务（比如金融交易系统的定时结算），你可能需要考虑更精确的方案。

再说一个底层细节：crond 在识别 crontab 文件是否变化时，并不是每次启动都重新读取文件全量解析，而是通过比较文件的修改时间（mtime）来决定是否重新加载。所以如果你修改了 crontab 文件但 mtime 没变（比如你用touch -r强行改回时间戳），crond 可能压根感知不到你的修改。这个坑比较冷门，但如果你有自动化脚本在批量修改 crontab，记得不要动时间戳。

除了触发机制，cron 的环境也非常特殊。它执行任务的时候并不加载/etc/profile、~/.bashrc这类登录 shell 环境，它只会设置一个最小化的环境。默认情况下，PATH 通常是/usr/bin:/bin，可能不包含/usr/local/bin，也不包含你自定义的 JAVA_HOME、PYTHONPATH 之类变量。这就是文章开头那个“脚本手动执行正常、放 cron 里就不行”问题的最常见原因。

解决办法有两种，我一般推荐在脚本里自己加好环境变量，而不是把希望寄托在 crontab 的全局配置上：

• 在 crontab 顶部显式定义环境变量，例如JAVA_HOME=/usr/local/java、PATH=/usr/local/bin:/usr/bin:/bin。
• 在脚本第一行附近手动 source 需要的环境配置文件，或者直接把关键变量写死在脚本里。

这里还有个更隐蔽的问题：如果 crontab 里命令输出比较多，crond 会把这些输出通过邮件（mail）发给当前用户。很多服务器没有配置邮件服务，导致输出被丢弃或者堆积在 mail spool 里。我的建议是：非调试阶段，所有任务一律重定向输出到日志文件，比如：

0 6 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

原因很简单：一旦任务失败，这些日志就是你排查问题的第一手资料。如果你不重定向，等你要排查问题时才发现输出全丢了，那才叫欲哭无泪。

还有一种更隐蔽的情况：cron 执行任务时，它的工作目录（当前目录）默认是用户的主目录，而不是脚本所在目录。所以脚本里如果使用了相对路径，执行时大概率会报 “No such file or directory”。妥善做法是脚本内部统一使用绝对路径，或者在 crontab 行内先cd /your/dir &&再执行命令。

4. 任务不执行？我常用的五步排查链路

这部分是真正的干货。我把这些年排查 cron 任务的经验总结成一套固定的排查链路，遇到“任务就是没跑”或者“跑了但结果不对”的情况，你按这个顺序走一遍，大部分问题都能定位。

4.1 先确认服务本身活着没

很多简化安装的 VPS 或 Docker 容器里，crond 服务默认根本没启动。先执行：

systemctl status crond # 或者 service cron status

不同发行版服务名略有差异，CentOS/RHEL 系通常是crond，Debian/Ubuntu 系通常是cron。如果服务没在运行，直接启动并设为开机自启：

systemctl start crond systemctl enable crond

在容器场景下尤其注意：很多精简镜像不会自动启动 cron 服务，你得在 Dockerfile 或者 entrypoint 脚本里手动把它拉起来，否则即使 crontab 配置再正确也是白搭。

4.2 查看日志，cron 会诚实记录每一次执行

确认服务正常后，看日志。多数 Linux 发行版上，cron 的执行记录会写在/var/log/cron（RHEL 系）或者/var/log/syslog（Debian 系，其中筛选 cron 相关记录用 grep）。

# RHEL/CentOS grep CRON /var/log/cron # Debian/Ubuntu grep CRON /var/log/syslog

日志里能看到每一次任务的触发记录、执行用户和具体的命令。如果日志里根本没有你的任务记录，说明 crontab 内容可能没加载进去，或者 crond 压根没读取到你修改后的配置文件。如果日志里有记录，但脚本执行结果不对，那问题大概率出在脚本本身——可能是环境变量缺失、权限不足、或者脚本依赖的服务还没就绪。

举个例子，这是我机器上的一段真实日志片段：

Jun 10 03:00:01 myhost CROND[12345]: (root) CMD (/usr/local/bin/backup.sh) Jun 10 03:00:02 myhost CROND[12346]: (root) CMD (echo "test" >> /tmp/test.log)

从时间戳看，任务确实在 03:00:01 被触发了。此时你要做的，是去检查 backup.sh 有没有产生日志，有没有报错输出。

4.3 手动执行脚本，把环境变量差异暴露出来

一旦确认任务被触发了，就把脚本拿到命令行手动跑一遍。但注意，是用和 cron 一样的环境跑，不是用你的登录 shell 环境。

su -s /bin/bash www-data -c '/usr/local/bin/backup.sh'

用su切换成 crontab 所属用户执行，可以最大程度模拟 cron 的环境。如果你直接在当前用户的登录 shell 里测试，环境变量完全不一样，测试结果几乎没有参考价值。

如果当前用户在 crontab 里的环境变量不足，你可以临时在脚本前面 source 一下环境配置文件来做验证。但我不建议这样做——正确做法是让脚本自身脱离对登录环境的依赖。

4.4 检查文件权限和脚本解释器

这步很多人会漏。cron 在执行任务时，会检查当前用户对脚本是否有执行权限。如果脚本没有x权限，cron 会直接报错，但在日志里不一定会有清晰的错误提示。

ls -l /usr/local/bin/backup.sh

正确的做法是用绝对路径指定脚本，并确保脚本第一行有正确的 shebang：

#!/bin/bash

如果你用crontab -e编辑时写的是sh script.sh，那 sh 可能指向 dash（在 Debian 系上），而你的脚本里用了 bash 专属语法，就会报语法错误。这类问题非常隐蔽，因为手动执行bash script.sh正常，但 cron 调用sh script.sh就崩了。

4.5 排除 SELinux、AppArmor 等安全模块干扰

如果上面四步都没问题，任务还是不正常，那就需要考虑安全模块了。有不少 Linux 发行版默认开启了 SELinux（比如 CentOS 7 及以后版本），即使你用 root 用户配置 cron，SELinux 策略也可能阻止 cron 上下文去执行某些脚本。

快速验证方法：临时把 SELinux 设为 permissive，看任务是否恢复正常。

setenforce 0

如果设成 permissive 后任务正常，那基本就是 SELinux 策略挡住了。背后是脚本文件的 SELinux 上下文类型可能不正确。常规做法是给脚本打上bin_t类型标签，或者调整布尔值允许相关操作。同样的逻辑也适用于 AppArmor（多用于 Ubuntu 系）。

提示：在排查阶段临时关闭 SELinux 可以，但记住排查完一定要恢复 enforcing 模式，并找到正规的放行方式，不要图省事长期关闭，那等于把一个安全层整个拆掉了。

5. 除了 cron，还有哪些计划任务工具值得用？

cron 能覆盖 80% 以上的定时任务需求，但有些场景它确实不给力。比如笔记本会睡眠关机，到了预设时间机器没开机，任务直接错过；再比如任务执行依赖某个服务，服务没起来时任务跑了也是白跑。这些情况下，下面几个工具能帮你补位。

5.1 anacron：专为“非全天开机”机器设计

anacron 的设计初衷很简单：如果系统在计划时间点没开机，那么启动之后会尽快补跑错过的任务。注意它只能管理“天”级别的任务，不是分钟级的。

如果你在/etc/anacrontab里配置任务，格式会不太一样：

# 延迟时间（分钟） 任务标识 命令 1 5 daily_backup /usr/local/bin/backup.sh

含义是：开机后延迟 5 分钟执行 daily_backup 这个标识的任务（如果当天还没执行过的话）。用它的好处是，笔记本用户第二天开机时，昨天的备份任务不会被吞掉。

5.2 systemd timer：新时代的推荐选择

如果用一句话评价 systemd timer：它把 cron 的定时能力，和 systemd 服务的完整依赖管理能力结合在了一起。你可以定义某个 timer 单元，依赖某个服务启动后再执行，可以在任务失败时自动重试，还可以精确到秒级周期。

一个最小示例，先写服务单元/etc/systemd/system/backup.service：

[Unit] Description=My backup job [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh

再写 timer 单元/etc/systemd/system/backup.timer：

[Unit] Description=Trigger backup every night [Timer] OnCalendar=*-*-* 03:00:00 Persistent=true RandomizedDelaySec=300 [Install] WantedBy=timers.target

然后启用 timer：

systemctl daemon-reload systemctl enable --now backup.timer systemctl list-timers

其中有几个参数值得展开说说。Persistent=true是 systemd timer 对标 anacron 的关键：如果系统在设定时间点是关机的，下次开机后会立即补跑错过的任务。RandomizedDelaySec=300表示触发后随机延迟最多5分钟，用于避免大量机器同时跑任务把服务器打爆，在集群环境尤其好用。OnCalendar=*-*-* 03:00:00的格式和 cron 五段式不同，是“年-月-日 时:分:秒”，用户需要适应一下，但表达能力更强，甚至可以写Mon,Fri *-*-* 00:00:00之类的复杂组合。

5.3 at：临时一次性任务

如果你只是“今晚 11 点帮我重启一下这个服务”，不想为它建 crontab（因为建完还得记得删），那么at是更干净的选择：

echo "systemctl restart myapp" | at 23:00

也可以用交互式方式：输入at 23:00回车，然后输入要执行的命令，最后按 Ctrl+D 结束。用atq可以查看当前排队的任务，atrm 任务号可以取消任务。

5.4 几个工具的选型对照表

看到这里你可能会问，既然 systemd timer 这么强，是不是该彻底抛弃 cron？我的观点是：别急着迁移。如果你的存量服务器上已经有一堆 crontab，它们运行稳定，那就继续用，没必要为了“新”而“新”。新部署的服务可以考虑用 systemd timer，但也要注意团队里是否有人不熟悉 systemd 的语法。说到底，计划任务的本质是“在正确的时间做正确的事”，工具只是手段，稳定可靠才是目标。

6. 两个可以直接抄作业的实战案例

前面讲的都是基础知识和理论，现在来谈谈实际落地。我给两个真实场景的配置，拿回去改改路径就能用。

6.1 案例一：Nginx 访问日志自动切割

日志切割用 logrotate 才是正解，但很多人会手动写脚本切日志。我用 cron 配合 logrotate 来演示一个完整流程。

先确认 logrotate 已安装，然后配置/etc/logrotate.d/nginx：

/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 nginx adm sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` endscript }

然后写 crontab，让 logrotate 每天凌晨执行：

0 0 * * * /usr/sbin/logrotate -s /var/lib/logrotate/logrotate.status /etc/logrotate.conf >> /var/log/logrotate.log 2>&1

有些发行版已经默认配置了/etc/cron.daily/logrotate，那你不需要再加 crontab。但如果你管理的是自建环境、精简容器，很有可能需要手动加。加的时候注意-s指定 status 文件路径，否则 logrotate 可能无法正确记录轮转历史。

6.2 案例二：MySQL 每日自动备份并清理旧备份

我用了很多年的一个备份脚本，结构很简单，核心逻辑就三件事：导出、压缩、清理。

#!/bin/bash # mysql_backup.sh BACKUP_DIR=/data/backups/mysql DB_USER=root DB_PASS='your_secure_password' KEEP_DAYS=7 DATE=$(date +%Y%m%d_%H%M%S) mkdir -p "$BACKUP_DIR" # 导出所有数据库（排除系统库） mysqldump -u"$DB_USER" -p"$DB_PASS" --all-databases --ignore-table=mysql.event | gzip > "$BACKUP_DIR/mysql_$DATE.sql.gz" # 清理超过保留天数的备份 find "$BACKUP_DIR" -name "mysql_*.sql.gz" -mtime +"$KEEP_DAYS" -delete # 记录备份日志 echo "$(date '+%F %T') backup finished" >> /var/log/mysql_backup.log

crontab 这样写：

0 2 * * * /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup_cron.log 2>&1

选择凌晨 2 点是因为此时业务访问量低，mysqldump 对线上性能影响最小。切记：脚本里密码不要裸写在 crontab 里，而是放在脚本文件里并设置仅 root 可读：

chmod 700 /usr/local/bin/mysql_backup.sh chown root:root /usr/local/bin/mysql_backup.sh

还有一个经验：备份脚本里一定要处理磁盘空间满的情况。我的做法是脚本开头检查磁盘剩余空间，低于 20% 时直接发一封邮件通知，避免备份把磁盘写爆。

AVAIL=$(df "$BACKUP_DIR" | awk 'NR==2 {print $5}' | sed 's/%//') if [ "$AVAIL" -gt 80 ]; then echo "磁盘使用率超过80%，备份中止" | mail -s "MySQL backup disk warning" ops@example.com exit 1 fi

7. 关于时区、夏令时和 cron 的兼容性提醒

计划任务里还有一个容易被忽视的维度：时区。cron 读取的时间基准是系统时区，不是 UTC 也不是你大脑中的“北京时间”。如果你的服务器时区设置错了，所有任务都会按错误的时间执行。

检查当前时区：

timedatectl

希望任务在“北京时间每天早上 8 点”跑，但系统时区是 UTC，那你需要在 crontab 里写0 8 * * *，但实际触发时间是 UTC 8 点 = 北京时间 16 点。解决办法是把系统时区改成东八区：

timedatectl set-timezone Asia/Shanghai

另一个冷门问题跟夏令时有关。部分使用夏令时的国家和地区，在时间切换日会出现“每天两个小时没有 02:30”或者“某天有两次 02:30”的情况，cron 对这类边界情况的处理在不同实现里并不一致，有的会正确执行一次，有的会执行两次，有的直接跳过。国内没有夏令时，这个问题很少有人遇到，但如果你管理的是海外服务器，还是留个心眼比较好。

还有容器场景的额外提醒：容器的/etc/localtime可能继承自宿主机，也可能因为镜像精简而缺失。如果你的容器里跑 cron，进入容器先执行timedatectl或者date确认时间基准对不对。我见过一个很搞笑的线上事故：服务器时区正确，但容器内时区是 UTC，导致所有容器里的 cron 任务都比预期晚了 8 小时才触发。

8. 把 crontab 纳入版本管理和审计

最后谈一个“运维规范化”层面的经验，虽然不算纯技术，但我觉得特别值得写下来。

很多人管理 crontab 的方式是直接在服务器上crontab -e，改了就完事。问题在于：crontab 文件没有历史记录，哪天误删了一行，或者被人悄悄改了，你根本不知道。等到任务出问题再回溯源，已经无法查证当初的状态。

我的建议是：把所有 crontab 文件集中管理，纳入 Git 仓库。具体做法很灵活，我自己的习惯是这样：

1. 把每台机器的 crontab 导出到统一目录，文件名按主机名区分。
2. 需要修改时，先在该机器上导出当前配置，用脚本做 diff 对比，没有问题再推上去。
3. 用 Git 做变更记录，这样每次改了什么、为什么改，都有迹可循。

导出当前用户 crontab 用crontab -l，保存到文件后用crontab 文件名恢复。注意crontab -l在无任务时会报错，所以导出前先做个判断。

crontab -l > /opt/cron_backup/web01.cron 2>&1 || true

如果你的服务器数量比较多，也可以考虑直接管理/etc/crontab、/etc/cron.d/下的文件，配合配置管理工具（Ansible、SaltStack 等）下发。这样带来的额外好处是：新机器初始化时，几秒钟就能把整套计划任务同步过去，不用一台一台手工敲。

我还习惯在 crontab 文件头部写清楚维护人的联系方式，以及任务的关键说明。不要小看这几行注释，等三个月后你自己回来看这个文件，会发现救命之恩全在注释里。

# Managed by ops team, contact: ops@example.com # Every day at 02:00, backup mysql databases. Keep 7 days. 0 2 * * * /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup_cron.log 2>&1

最后分享一个很小的技巧

如果你管理的机器上有多个用户的 crontab，比如 root 一个、www-data 一个、postgres 一个，建议把任务日志的命名统一起来，带上用户和任务名。我设了一个约定：所有 cron 任务日志都写入/var/log/cron_tasks/{user}_{task_name}.log。这样做的好处是，出问题时一条命令就能看到某台机器上所有 cron 任务的状态：

grep -r "" /var/log/cron_tasks/ | tail -50

比起到每个用户目录下翻邮件、找输出文件，这个习惯帮我节省了太多时间。很多人只在意怎么写 crontab，却忽略了日志管理，等到真的要排查的时候才发现连一点线索都没有。计划任务本身不复杂，复杂的往往是你对它是否足够尊重——提前想到环境差异、日志留存、权限边界，后面才会少踩一些坑。