RHCE定时任务全解析：crontab、at与logrotate实战指南

1. 先搞清楚RHCE定时任务到底考什么

很多备考RHCE的朋友一看到“定时任务”这四个字，脑子里蹦出来的就是crontab -e然后写一行* * * * * command。这个印象不能算错，但要说这是RHCE定时任务的全部，那就太天真了。我在帮学员做考前辅导时，经常发现大家对定时任务的认知停留在“能用就行”，结果真上了考场，在at、/etc/cron.d、run-parts这些地方栽跟头的大有人在。

先明确一点：RHCE的定时任务考点在官方考纲里通常归在“配置定时任务”这个系统管理能力域下面，但它实际考察的深度远超“写一条cron规则”。根据历年考题和红帽官方课程RH134/RH294的内容来看，下面几张“牌”你至少要完全摸透：

• 用户级crontab文件，也就是crontab -e维护的那个文件，以及如何在非交互场景下用crontab命令导入、导出、删除配置。
• 系统级cron配置，也就是/etc/crontab、/etc/cron.d/目录下的文件，还有/etc/cron.hourly、/etc/cron.daily、/etc/cron.weekly、/etc/cron.monthly这些按时间周期执行的目录。
• 一次性定时任务at，包括atd服务状态、at任务的提交和查看、/etc/at.allow和/etc/at.deny的权限控制逻辑。
• 与cron深度绑定的日志轮转机制logrotate，考试不会直接问“logrotate是谁驱动的”，但要你配置日志轮转时，你会发现它的运行基础就是cron。

为什么我强调要“搞明白考点范围”？因为考试环境是限时的。如果你在定位题目要求时搞不清楚“用户级任务写crontab -e”和“系统级任务写/etc/cron.d/文件”的区别，一个看似简单的配置题可能耗掉你十几分钟。这套区分逻辑在真实生产环境里更重要：应用自己的定时任务放在/etc/cron.d/下会便于管理，而随意修改/etc/crontab、占用了系统预留字段，稍不注意就会把整个系统的定时任务搞乱。

1.1 考点背后其实是“服务管理 + 文件权限 + 环境变量”的综合体

很多考生把定时任务题目当成单纯的“写配置题”，这是应试上最大的误区。定时任务要真正跑起来，依赖的是一整套系统机制：

第一，crond服务必须在线。现代RHEL基本默认开机自启，但考试环境里如果被故意停掉了，你配置得再漂亮也不会执行。能用systemctl status crond确认，就需要用systemctl enable --now crond拉起来。

第二，文件权限要合法。用户级crontab文件通常不应该被普通用户手动改权限或属主，/etc/cron.d下的文件则要注意属主和属组不能是普通用户可写的，否则cron会拒绝加载并报权限错误。

第三，cron执行任务时的环境变量极简。它不会加载你登录Shell里的~/.bashrc或~/.bash_profile，PATH往往只有/usr/bin:/bin这种基础路径。你的脚本如果在脚本内用了相对路径或者依赖自定义环境变量，十有八九会“手动执行成功、cron执行失败”。

弄明白这三点，你再看RHCE定时任务题，就会发现它根本不是“考背语法”，而是在考“你了不了解Linux任务调度的整个运行链路”。接下来我按实际考试和真实运维中最常遇见的几个模块，一个一个拆开讲。

2. crontab 语法拆解与考场易错点

crontab的五位时间字段大概是Linux里最经典、也最容易出错的语法之一。分 时 日 月 周，这个顺序我建议你刻进DNA：分钟在前，小时在后，然后是日、月、周。为什么顺序这么“反直觉”？因为C语言的struct tm结构体里就是按这个排列的，minute在最前面，这个历史包袱一直延续到今天。理解了这一点，你就不容易把它和Java定时任务框架里的cron表达式搞混了。

2.1 和Java cron表达式划清界限：我们是五段，不是六段

在备考群和运维交流群里，我见过不下十次这样的场景：一个从Java转过来的同事，写Linux crontab时下意识地写出这样的配置：

cron复制# 错误示范：Java 风格六段，Linux cron 不认
0 0 12 * * ? /usr/local/bin/backup.sh

后面那个?在Linux cron里是非法字符。Java的cron表达式有六段甚至七段（秒 分 时 日 月 周），而Linux crontab只有五段，没有“秒”这一维度，也没有?这种“不指定”的通配。这一点在RHCE考试中不一定会直接考，但你要是把两种语法混着写，改半天都查不出错。

合法的五位时间字段支持这些写法：

注意两个比较冷门的细节：第一，周字段的0和7都代表周日，所以0 2 * * 7和0 2 * * 0意思是完全一样的，都是“每周日凌晨2点”；第二，日和周同时设置时，cron的判断逻辑是“或”而不是“与”。什么意思？0 0 1 * 1表示“每月1号或者周一（满足任意一个就执行）”，而不是“每月1号且恰好是周一才执行”。这个坑我实测过，也害过很多考生，因为人的直觉往往是“与”。但cron的源代码逻辑就是if (dom matches || dow matches)。简单说：如果你想表达“每月1号且这天的确是周一”，光靠cron做不到，你只能在脚本里自己加判断。

2.2 用crontab -e编辑，还是直接用vim /etc/crontab

考试中很常见的要求是“为用户natasha配置定时任务，每天14:23执行/usr/bin/echo hello”。这时候标准做法是：

bash复制crontab -e -u natasha
# 或切换到natasha用户后 crontab -e

然后写入：

cron复制23 14 * * * /usr/bin/echo hello

有些考生觉得“用root直接改/etc/crontab不是更快吗？”——能跑，但不符合要求，而且/etc/crontab是系统级配置文件，第六个字段才是要执行的命令，也就是分 时 日 月 周 用户 命令。你少了用户字段，哪怕写对了时间，这条任务也不会按预期执行。RHCE考试对“是不是按要求的方式实现”看得很重，题目说crontab -e配置用户级任务，你就老老实实用这个方式。

这里还牵扯出一个非交互操作技巧：考试或自动化脚本里没法直接打开crontab -e的编辑器，怎么办？我常用的做法是准备一个文本文件，然后：

bash复制# 把任务规则写入文件，然后整体导入
echo '23 14 * * * /usr/bin/echo hello' > /tmp/natasha.cron
crontab -u natasha /tmp/natasha.cron

# 验证
crontab -u natasha -l

这个方式非常适合在脚本中一键配置。反过来，你想清空某个用户的全部任务，用crontab -r -u natasha就行。不过-r要慎用，尤其是生产环境，它不会跟你确认，直接删光。

2.3 环境变量坑：为什么手动执行正常，cron执行报错

这是我在实际运维中遇到频率最高的问题，也是考试中经典的“陷阱题”。

cron执行任务时，默认PATH极其精简。我在RHEL 9上实测，crond服务的默认PATH基本是/usr/bin:/bin。你自己登录Shell后执行which java找到的是/usr/local/java/bin/java，但cron里直接写java -version，大概率会得到java: command not found。

解决方案有两种，我更推荐第一种：

bash复制# 方案一：脚本内或命令前使用绝对路径
23 14 * * * /usr/local/java/bin/java -jar /opt/myapp/app.jar

# 方案二：在crontab文件开头重新定义PATH
PATH=/usr/local/java/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
23 14 * * * java -jar /opt/myapp/app.jar

在crontab文件里允许以KEY=VALUE的形式设置环境变量，PATH、MAILTO、SHELL都支持。除此之外，你可以在/etc/crontab里设置系统级的环境变量，但更常见的是直接在用户自己的crontab文件顶部设置。

还有两个环境变量相关的细节值得注意：

• MAILTO：任务执行产生的标准输出和错误输出，默认会以邮件形式发送给该任务的属主。考试环境往往没配邮件服务，这时候任务输出会积压在/var/spool/mail/下。我通常会在测试期把MAILTO=""，不想看一堆垃圾邮件。
• SHELL：cron默认用/bin/sh执行命令，不是/bin/bash。如果你的命令用到了bash特有的语法（比如[[ ]]、数组），最好显式写成/bin/bash -c '你的命令'，或者在crontab里设置SHELL=/bin/bash。

2.4 最容易看走眼的“每周三凌晨2点半”怎么写

来看个实际例子：要求“每周三的凌晨2:30执行/opt/scripts/weekly.sh”。

初学者容易写成30 2 * * 3 /opt/scripts/weekly.sh，这看起来没错。但真正容易出错的变体是：“每月的第一个周三执行”或者“每隔两小时执行一次”。

• 每隔两小时：0 */2 * * *，注意不是* */2 * * *。后者是“每小时的每分钟都执行，且每两小时一次”，等于每小时执行60次，结果完全不对。
• 每月的第一个周三：cron五段语法表达不了，写在脚本里判断date +%d是否在1~7之间，且date +%w等于3。
• 每天23:00到次日凌晨5:59之间的每小时执行一次：0 23-5 * * *这种跨小时段的写法在cron里不识别，你只能拆成两条规则：0 23 * * *和0 0-5 * * *。

这些“看似简单但容易翻车”的写法，才是RHCE考场真正的分水岭。

3. 系统级定时任务：/etc/cron.d 家族与 run-parts 机制

用户级crontab适合解决“某个用户自己的任务”。但真实服务器上还有大量需要系统级调度的工作，比如日志切割、临时文件清理、系统状态采集。这种情况下，直接在/etc/crontab里堆配置会导致文件杂乱，而且很难和软件包自带的定时任务隔离。RHEL的解决方案就是/etc/cron.d/目录和cron.hourly这类目录。

3.1 四个位置的分工，别再傻傻分不清

RHEL里和cron相关的系统级配置位置，我整理过一张表：

/etc/cron.d/下面的文件，规则和/etc/crontab完全一样，第六列必须写执行用户。比如我在生产环境部署了一个内部状态上报脚本，我会在/etc/cron.d/下创建文件status-report：

cron复制# /etc/cron.d/status-report
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

*/5 * * * * root /usr/local/bin/status-report.py --config /etc/status-report.yaml

注意：文件名不要带点号。cron对/etc/cron.d/下文件名有个隐含要求——如果文件名包含.，它会被忽略。我第一次写daily.cleanup这个文件时，cron日志里完全看不到任务加载记录，排查了很久才从man cron的说明里发现这个约束。这也是考试里可能出现的坑：你放对了目录、写对了格式，结果文件名带个点，系统就是不执行。

3.2 run-parts 到底做了什么

/etc/cron.hourly这类目录本身不是cron语法，而是一堆脚本文件。谁去执行它们？答案是run-parts命令。在RHEL上，/etc/crontab文件里默认就有这些行：

cron复制SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

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

run-parts会遍历指定目录下的所有可执行文件，然后逐个执行。它有一个非常重要的行为：目录下文件名必须符合“仅由字母、数字、下划线和连字符组成”的规则，否则会被跳过。我习惯在/etc/cron.daily/下放的脚本如log-cleanup、backup-db，不带.sh后缀，就是因为.sh里面有.会被run-parts忽略。

RHCE考试里要求“将某个脚本放到系统每日任务目录”，你直接把脚本复制到/etc/cron.daily/并加执行权限即可：

bash复制cp /opt/scripts/daily_report.sh /etc/cron.daily/daily_report
chmod +x /etc/cron.daily/daily_report

脚本没有执行权限，run-parts也不会执行它。这一点很多人忽略。

3.3 自己动手写一个系统级定时任务

假设需求是：每天凌晨3点以root身份运行/opt/scripts/backup.sh，同时把标准输出和错误都记录下来。

我推荐在/etc/cron.d/下创建独立文件，而不是改动/etc/crontab。原因很简单：独立文件职责单一、便于管理，卸载软件时删掉对应文件就行；而/etc/crontab改动多了容易引发冲突。

bash复制cat > /etc/cron.d/app-backup << 'EOF'
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

0 3 * * * root /opt/scripts/backup.sh >> /var/log/app-backup.log 2>&1
EOF

这里有几个细节顺便说一下：

• 2>&1把错误输出合并到标准输出，日志排查时非常有用。
• cron命令的标准输出默认发邮件给root，重定向到日志文件后可以避免邮件堆积。
• 如果用>>追加而不是>覆盖，日志能保留历史记录，生产环境建议始终追加。

4. 一次性定时任务：at 命令的隐藏考点

cron解决的是周期性任务，但现实里还有另一类需求：某条命令“今天下午5点跑一次”，或者“30分钟后重启服务”。这种一次性任务，正确姿势是at，而不是在cron里写一条过几分钟就失效的规则。RHCE考试里at出现的频率比很多人想象的高，而且一旦考到，往往是权限控制和命令使用方式一起考。

4.1 先确认atd服务是活的

at命令本身只是个客户端，真正干活的是atd服务。如果atd没启动，你提交任务会直接报Cannot open lockfile /var/spool/at/.lock这类错误。

bash复制systemctl status atd

没启动就启动并设置开机自启：

bash复制systemctl enable --now atd

4.2 提交任务的几种姿势

最简单的交互式提交：

bash复制$ at 17:00
warning: commands will be executed using /bin/sh
at> /opt/scripts/deploy.sh
at> <EOT>   # 按 Ctrl+D 结束输入
job 5 at Wed Oct 18 17:00:00 2025

另一种方式更适合脚本自动化：把要执行的命令写入文件，然后通过-f指定文件提交。

bash复制echo '/opt/scripts/deploy.sh' > /tmp/deploy.job
at -f /tmp/deploy.job 17:00

几个实用的at时间格式：

查看当前排队的一次性任务用atq，删除指定任务用atrm 任务编号。这三个命令是配套的，考试里经常会要求“查看natasha用户当前排队的at任务”，对应的答案就是atq或者at -l。

4.3 at.allow 和 at.deny 的权限逻辑

RHCE考点里和at挂钩最多的，其实是权限控制。RHEL上at命令的权限由/etc/at.allow和/etc/at.deny两个文件决定：

• 如果at.allow存在，只有写在这个文件里的用户能使用at，at.deny被忽略。
• 如果at.allow不存在但at.deny存在，则不在at.deny里的用户都能使用at。
• 如果两个文件都不存在，只有root能使用at。
• 空白的at.deny文件（存在但不含内容）表示允许所有用户使用at。

RHEL默认情况是只有空白的/etc/at.deny存在，所以所有用户都被允许。题目如果要求“禁止user1使用at命令”，你直接把他加进/etc/at.deny即可：

bash复制echo 'user1' >> /etc/at.deny

或者反过来，创建/etc/at.allow，只允许user1使用。两种做法都能达到目的，但要知道它们的区别，别混着来。

4.4 batch：系统空闲时才执行的at

at的变体命令batch很少在教程里被提及，但它是“系统负载低时执行任务”的标准工具，原理是任务提交后进入队列，当系统负载均值低于0.8（具体阈值有时会配置为1.5）时才真正执行。

考试考它的概率不高，但你在真实环境里如果遇到“备份任务不着急，别在业务高峰抢占资源”这种需求，用batch比自己在shell脚本里死循环判断load average要靠谱得多。

5. logrotate 与定时任务的联动

RHCE考试不会单独考“logrotate命令的语法”，但考纲里涉及“配置日志轮转”时，你必须理解其背后的定时机制。很多人在配置日志轮转时，明明/etc/logrotate.conf里改好了，但就是不按时执行。原因很简单：你改的是配置，但触发它执行的开关在cron这边。

5.1 logrotate不是独立服务，它靠cron吃饭

RHEL系统上，logrotate的入口脚本放到了/etc/cron.daily/logrotate。也就是说，它默认每天执行一次（具体时间由/etc/crontab里的02 4 * * * root run-parts /etc/cron.daily决定，通常是凌晨4点02分）。所以，如果你在logrotate.d里配置的轮转条件是daily，含义是“每天凌晨4点02分时检查日志是否需要轮转”，而不是“日志写满24小时后立刻轮转”。

这个细节有多重要？有一次我在生产环境新增了一个应用日志，配置了daily加rotate 7，满心以为7天后旧日志会被清掉。结果过了10天去看，/var/log/myapp/底下文件数量还在涨，8天、9天的日志都在。排查才发现logrotate主配置里有个全局的weekly默认值，我的应用配置文件没有覆盖daily，导致实际执行频率是周检。这类问题的根源在于：你没意识到logrotate的“频率”不是精确到分钟的系统调度，而是每天检查一次。

5.2 一份典型配置的字段语义

以应用日志为例，看一份实际在用的/etc/logrotate.d/myapp配置：

conf复制/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp myapp
    sharedscripts
    postrotate
        /usr/bin/systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

逐行解释一下：

• daily：每天检查一次，实际是配合cron.daily的节奏。
• rotate 14：保留14份历史日志，超过就删最老的。
• compress：轮转后的旧日志用gzip压缩。
• delaycompress：上一轮的日志先不压缩，等下一轮再压。很多应用日志压缩后还在被写入句柄，立刻压缩容易丢最后一段内容。
• missingok：日志文件不存在也不报错。
• notifempty：日志为空时不轮转。
• create 0640 myapp myapp：轮转后新建日志文件的权限和属主。
• sharedscripts：如果通配符匹配多个文件，postrotate脚本只执行一次，而不是每个文件都执行。
• postrotate：轮转完成后执行的动作。这里是个超级关键点——日志文件被改名后，应用进程持有的还是旧文件的文件描述符，不通知应用重开日志文件，新日志就会继续写到已经轮转掉的那个文件上。

考试里如果考logrotate，大概率会给你一段有问题的配置让你修正，常见问题包括：忘记create导致新日志文件权限不对、没有postrotate导致日志写完旧文件、rotate数量设置过小导致历史日志被过早清理。这些细节平时手动处理日志时几乎全都会踩一遍。

5.3 手动触发logrotate验证配置

配置好logrotate后，不需要真的等第二天凌晨4点验证。可以手动执行一次并进入调试模式：

bash复制# -d 只模拟执行，不真正轮转，输出详细的决策过程
logrotate -d /etc/logrotate.conf

# -f 强制轮转，即使还没到轮转条件
logrotate -f /etc/logrotate.conf

我强烈建议在生产环境用-d先跑一遍，确认配置没语法错误、文件路径正确，再使用-f强制轮转。强制轮转一个刚写了一点内容的日志文件，是会立即触发postrotate脚本的，如果脚本里systemctl reload对应的服务有问题，立刻就能暴露。

6. 动手练一遍：RHCE风格定时任务完整练习

理论讲了这么多，不如完整过一道RHCE风格的练习。这道题是我在备考群里经常发的一种综合练习，它把cron、at、logrotate、权限控制串联到了一起，非常接近真实考试的综合压轴题。

6.1 练习题目（自拟）

1. 为系统创建用户 natasha，并设置密码。
2. 为 natasha 配置 crontab 任务：每天 21:30 执行 /usr/local/bin/backup.sh，脚本有可执行权限。
3. 禁止用户 harry 使用 at 命令。
4. 在 /etc/cron.d/ 下创建系统级任务，让 /opt/scripts/health-check.sh 每 2 小时执行一次，且只允许在每天 8:00 到 20:00 之间执行（即8点、10点、12点……20点）。
5. 配置 logrotate，让 /var/log/healthcheck/health.log 按天轮转，保留7份，压缩，并设置权限 0640 root root。

6.2 逐步解题与验证

第一题是RHCSA基础，直接一条命令：

bash复制useradd natasha
echo '你的密码' | passwd --stdin natasha

注意：RHEL 9 上passwd --stdin其实已经不建议使用了，但脚本自动化里还是很常用。考试环境一般没这个限制，你也可以用chpasswd。

第二题，先写本地规则文件再导入：

bash复制cat > /tmp/natasha-cron << 'EOF'
30 21 * * * /usr/local/bin/backup.sh
EOF
crontab -u natasha /tmp/natasha-cron
crontab -u natasha -l

建议导入前先确认/usr/local/bin/backup.sh存在且属主是你预期的人。如果脚本不存在，cron照样会加载这条规则，但执行时全是报错邮件。

第三题，harry不允许用at：

bash复制echo 'harry' >> /etc/at.deny
# 验证：切换到harry执行at命令，应该被拒绝
su - harry -c "at now + 1 minutes"

这里有个小坑：/etc/at.deny里每个用户名一行，如果你在脚本里重复执行echo harry >>，会产生重复行。不影响功能，但不够整洁。更好的做法是用grep -qx判断后再追加。

第四题，/etc/cron.d/health-check：

bash复制cat > /etc/cron.d/health-check << 'EOF'
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

0 8-20/2 * * * root /opt/scripts/health-check.sh
EOF

注意这里我用的时间写法是0 8-20/2 * * *，表示“8点到20点之间，每2小时的整点”。所以执行时刻是8:00、10:00、12:00、14:00、16:00、18:00、20:00。如果写成*/2，就会变成“每两分钟的0秒”，语义完全不同。文件创建后，可以用ls -l /etc/cron.d/health-check确认属主是root。

第五题，logrotate配置：

bash复制cat > /etc/logrotate.d/healthcheck << 'EOF'
/var/log/healthcheck/health.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 root root
}
EOF

# 验证配置
logrotate -d /etc/logrotate.d/healthcheck

logrotate -d看完后，重点看输出的轮转条件和将要执行的动作。如果配置里路径写错或者目录不存在，-d阶段就会暴露。

6.3 踩坑记录：大多数人会在哪个环节翻车

结合我辅导学员的经验，这道练习里最容易翻车的位置集中在三个地方：

第一，crontab -u natasha /tmp/natasha-cron 这个导入方式很多人不熟。有些人直接切成natasha用户再crontab -e，在考试图形化或字符界面下反而容易误操作。记住：非交互式导入是更可控的方式。

第二，/etc/cron.d/下的文件要求带用户字段。0 8-20/2 * * * /opt/scripts/health-check.sh这种写法少写了root，cron加载时会直接忽略它，而且大部分情况下不报错，只在/var/log/cron日志里有提示。你从journalctl -u crond里能看到“ignoring line”之类的信息。

第三，logrotate的create 0640 root root和postrotate经常被漏掉。只写rotate 7不写create，轮转后新日志文件的属主会变成当前用户（此处是root），但文件的mode可能会继承旧文件的，如果旧文件权限是0600，新日志的权限就不符合题目要求。类似地，如果应用服务需要重开日志句柄而你没有postrotate，新日志会一直写到已被轮转的旧文件里，然后“新日志文件永远不增长”，排查起来非常隐蔽。

7. 日常排错三板斧：journalctl、/var/log/cron、手动模拟

最后再聊聊排错。考试和真实运维中，定时任务配置完不生效几乎是必然要面对的事。与其一次次“改了等半天看结果”，不如养成“查日志、模拟执行、逐层定位”的习惯。

7.1 先看crond到底加载了什么

排查cron问题的第一站是日志。RHEL 7以上，直接用journalctl看crond服务的日志：

bash复制journalctl -u crond --since "10 minutes ago"

如果cron加载了某条配置但拒绝执行，日志里通常能看到RELOAD、No such file or directory之类的线索。RHEL 9还会把具体的用户级任务错误输出写到/var/spool/mail/用户，我排错时经常去翻邮件文件，里面常常直接写着命令的报错输出。

7.2 手动模拟cron的环境

另一个百试百灵的技巧是：用cron的极简环境手动跑一次命令，复现问题。

bash复制# 模拟cron执行环境，不加载用户profile
env -i /bin/sh -c '/usr/local/bin/backup.sh'

如果这个模拟执行报错“command not found”或“No such file or directory”，基本就能确认是环境变量或相对路径的问题。解决思路就是我前面说的：脚本里写绝对路径，或者把PATH写进crontab文件顶部。

7.3 验证at队列别只靠猜

at任务是否在排队，用atq一眼就能看出来。但如果队列是空的，有两种可能：任务已经执行完并被移除，或者任务从未提交成功。看/var/log/cron同样能查到at任务的提交和执行记录。如果提交时就报错，八成是atd没启动、/var/spool/at目录权限不对、或者用户被/etc/at.deny拦住了。

实际工作中，我见过太多“以为定时任务没生效，最后发现是任务在跑但脚本每次都失败”的情况。定时任务这东西，配置只占了30%，剩下70%是权限、环境、日志、服务状态这些“周边系统”。你把周边这几个环节打通了，RHCE的定时任务题就是稳稳的送分题；将来到了生产环境，这一整套排查思路也会让你比同龄人少熬好几个夜。