企业官网建设流程全解析

1. 先搞懂这一章在讲什么：调度的三种方式

1.1 一次性、周期性与定时器：三类任务场景

RH134这门系统管理进阶课程的第2章，标题叫“调度未来任务”。你一听可能觉得玄乎，其实就是一句话：让Linux在某个指定的时间点，自动去执行你已经定义好的命令或脚本。学完这一章，你至少能搞定三类需求：第一类是我今天晚上要跑一个一次性任务，比如晚上11点关服务器、凌晨把某个数据同步脚本执行一次；第二类是周期性的，比如每天凌晨2点备份数据库、每周一早上清理日志；第三类是更精细的、更现代的调度方式，也就是systemd timer，它不光能按日历时间触发，还能按照“系统开机后多久”“上次任务激活后多久”这种相对时间来触发。

很多备考RHCSA/RHCE的人以为这一章就是背几个命令，比如at、crontab、systemctl list-timers，但实际上考试和实际运维考的是“你会不会在不同场景下选对工具”。而RH134这一章的价值就在于：它把一次性任务、周期任务、系统计时器和临时文件管理放在一条线里讲，让你不仅会敲命令，还能理解每类工具的适用边界和坑点。这篇文章我会按RH134第2章的知识点顺序，把at、cron、anacron、systemd timer、tmpfiles这些内容全部拆开，每个都给出完整用法、操作细节、规避坑点，以及考试里常见的考察方式。

1.2 从cron到systemd timer的迁移趋势

很多人习惯一看到“定时任务”就想到crontab，这没有错，cron在Linux里已经存在几十年了，极其稳定可靠。但如果你只盯着cron，后面会浪费掉一个更灵活的工具。RH134之所以在这一章放进systemd timer，不是因为cron要淘汰了，而是因为systemd已经成为几乎所有主流Linux发行版的基础，定时器单元可以直接复用service单元，资源管理、日志、依赖关系都能跟systemd生态打通。比如你可以让某个timer依赖某个服务启动后再触发，也可以通过systemctl控制定时器的启停状态，这在cron里做起来很别扭。

从实际工作来看，我现在新部署的机器上，能写成systemd timer的任务我基本都写成timer，只有一些极其简单的用户级周期任务才用crontab。不是说cron不好，而是timer在监控、补跑、防重叠、依赖管理这几方面更顺手。这一章你至少要建立这样一个概念：at管一次性、cron管传统的周期、systemd timer管更复杂的调度需求，三者不是互斥关系，而是互补关系。下面我们一个个展开。

2. 一次性任务调度：at命令全流程

2.1 at的时间表达式怎么写

先讲at，因为它最简单，也是RH134第2章一般会先提的工具。它的语义就是“在未来的某个时间点，执行一次我指定的命令”。交互式用法是直接敲at 时间，然后回车进入等待输入命令的状态，输入完成按 Ctrl+D 提交：

at 23:00 at> /usr/bin/systemctl stop httpd at> <EOT> job 1 at Wed Dec 25 23:00:00 2025

除了交互模式，更推荐用-f指定脚本文件：at -f /root/backup.sh 02:30。这样不容易输错，也方便复现。

at最核心的部分是时间表达。它不只接受传统的HH:MM，还接受很多人类友好的写法。我整理了一个速查表，你直接抄：

我自己最常用的是at now + 1 hour这种相对写法，因为很多时候我根本不需要卡死某个绝对时间，只需要“一小时后干个活”。要注意的是，at读取的是系统时区，如果你在虚拟机里测试at，发现时间总是差了8小时，先去查一下系统时区是否设置正确，不要一上来就怀疑at命令坏了。

另外，如果任务需要用到环境变量，比如脚本依赖某个变量，可以在交互模式下先赋值再提交，或者直接用系统默认环境。因为at任务是在提交时刻捕获当前环境变量的，这个行为跟cron不一样，新手容易忽略。你可以写at> export LANG=en_US.UTF-8再写真正要执行的那条命令。

2.2 atq、atrm与访问控制

任务提交后，怎么查看？atq命令列出当前用户所有待执行的at任务，root用户可以看全部用户的任务。输出第一列是任务号，比如1、2，后面是执行时间和队列。如果你想取消某个任务，用atrm 任务号即可。如果要看某个具体任务的内容，可以查看/var/spool/at/目录下的文件，里面就是提交时保存的脚本和元信息。

这里有一个实操点：at默认会向用户发送邮件告知任务执行后的输出，前提是系统里装了邮件服务。如果脚本里产生了大量输出又没做重定向，你的邮件队列可能被撑爆。所以我建议凡是用at跑脚本，都在命令后加> /var/log/xxx.log 2>&1，把标准输出和错误输出都写到日志文件里。这样一个是方便事后排查，另一个是不会产生无用的邮件，省得每次执行完还要去/var/mail/里翻东西。

关于访问控制，系统和cron类似，也提供了/etc/at.allow和/etc/at.deny两个文件。规则是这样的：

• 如果/etc/at.allow存在，则只有该文件中列出的用户可以使用at。
• 如果/etc/at.allow不存在，但/etc/at.deny存在，则除了/etc/at.deny中列出的用户外，其他用户都可以使用at。
• 如果两个文件都不存在，通常只有root可以使用at。

不同发行版默认情况有差异，有些发行版默认带一个空的at.deny文件，表示所有人可用。考试一般不考太细的默认差异，但要求你能判断“某个用户能不能用at”这类问题。记住优先级就够：allow优先、deny其次、都没有则默认root。

2.3 batch：系统空闲才执行的补充玩法

RH134的教材里一般还会提batch。batch是at命令的变体，它的语义是“当系统负载降到某个阈值以下时才执行”。实际上在多数Linux发行版中，batch就是at命令带上-b选项，默认负载阈值是0.8。也就是说，系统很忙的时候，任务会排队等待，等负载下降了再执行。

这个工具适用的场景很典型：比如你有一个数据压缩任务，不希望跟白天的在线业务抢CPU，就可以用batch提交。它的用法跟at完全一样，只是不用写时间表达式：

batch -f /root/compress.sh

不过在实际生产里，batch用的人并不是特别多，因为现代系统有了更精确的资源控制工具，比如systemd-run配合CPUQuota、cgroup限制等。但考试偶尔会考“哪个命令在系统负载低时执行任务”，答案就是batch，这个分不能丢。

3. 周期任务调度：crontab从入门到避坑

3.1 crontab五个时间字段拆解

周期性调度，传统上绕不开cron。crontab的语法核心是5个时间字段加一个命令：

分 时 日 月 周 命令

这5个字段的取值范围是：分钟0-59、小时0-23、日1-31、月1-12、周0-7（0和7都代表周日）。命令部分可以是单条命令，也可以是脚本路径，也可以是多个命令用分号或&&连接。下面是一个标准例子：

30 2 * * * /usr/bin/tar -czf /backup/etc_$(date +\%F).tar.gz /etc

这段的意思就是每天凌晨2点30分备份/etc目录。如果你要“每分钟都执行”，那就是* * * * * 命令；要“每5分钟”，可以用*/5 * * * * 命令。这个斜杠的含义是“步长”，它不光是格式问题，背后是一种简写约定。需要注意的是：在crontab文件里，%有特殊含义，它代表换行或重定向的边界，所以在命令里用到日期格式化时必须写成\%F这种转义形式，否则会出错。很多第一次配cron的人在这里被卡住半天。

crontab的编辑方式是crontab -e，它默认调用vi编辑器。查看当前用户的定时任务用crontab -l，清空所有任务用crontab -r。如果你想给其他用户创建任务，root可以用crontab -u 用户名 -e。这里我要强调一个教训：crontab -r不会跟你确认，一个手滑就直接清空了，所以当你只是想删除某一条时，千万别用-r，应该用-e进去手动删除那一行，或者备份一份再操作。建议养成习惯，定期crontab -l > /root/crontab_backup_$(date +%F).txt备份配置。

3.2 用户级与系统级cron配置

cron任务分两类：用户级crontab和系统级cron配置。普通用户通过crontab -e编辑的是用户级配置，这些文件存放在/var/spool/cron/（有些发行版是/var/spool/cron/crontabs/）下，文件名就是用户名。它们只能用5字段语法，命令前不需要写用户名。

系统管理员还可以在/etc/cron.d/目录下放置系统级crontab文件，特点是在时间字段和命令之间多出一个“用户名”字段，例如：

30 2 * * * root /usr/bin/systemctl restart httpd

另外还有/etc/crontab这个老牌系统文件，语法和/etc/cron.d/一样，也需要写用户名。常被人忽略的是/etc/cron.hourly/、/etc/cron.daily/、/etc/cron.weekly/、/etc/cron.monthly/四个目录。只要把脚本丢进对应目录，系统每天/每周/每月就会自动执行。但请注意，这四个目录的触发逻辑实际上依赖的是run-parts机制，而且在现代RHEL系发行版上，它们默认是被anacron驱动执行的，不是简单的cron周期。这一点放到后面第5节详细讲。

考试时经常给一个场景让你判断：“我想每天凌晨3点以root身份执行某个脚本，应该放哪里？”答案通常是/etc/cron.d/下新建文件，或者直接写进root用户的crontab。两种都对，但考试如果规定“不修改任何用户的crontab”，那你就得选/etc/cron.d/。这个判断题其实就是考你有没有理解用户级和系统级的区别。

3.3 最容易踩的坑：日与周是OR关系

我印象里，很多初学者甚至工作一两年的人都会犯一个错：以为crontab里“日”和“周”两个字段是AND关系。比如想表达“每月1号和每周五都执行”，有人写：

0 9 1 * 5 命令

这行的真实含义是：如果今天是每月1号，或者今天是周五，都执行。也就是OR关系！这个语义在POSIX规范里就是这么定义的，目的可能是为了避免“某个月1号恰好不是周五就漏执行”这种情况。但反过来说，如果你实际想要的是“每月1号且当天恰好是周五才执行”，用普通crontab是表达不出来的，需要借助外部判断，例如命令里写：

0 9 1 * 5 [ $(date +\%d) = "01" ] && echo "%执行"

反正记住一个口诀：日和周同时非*时，是“或”不是“且”。考试里出这种判断题的概率很高，不要跳进去。

3.4 环境变量与PATH问题

cron的另一个大坑是环境变量。用户在终端里能执行的命令，放到crontab里却报“command not found”，这类问题在运维群里天天有人问。原因是cron执行任务的时候，不会加载你在交互shell里的那些环境变量，它只从一个很简朴的默认环境出发。在RHEL系中，crontab任务的默认PATH一般是/usr/bin:/bin，很多系统管理员习惯把命令放在/usr/local/bin/或/opt/bin/，在cron里就跑不通。

解决办法有两个：一是命令全部写绝对路径，比如/usr/local/bin/myscript；二是在crontab文件开头自己定义PATH：

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=/root

我强烈建议第二种做法，因为你可以在一个地方把环境定好，后面的所有任务都受益。除了PATH，还有两个环境变量值得注意：SHELL默认是/bin/sh，不是bash，所以如果你脚本里用了bash特有的数组或其他高级语法，要么脚本第一行写#!/bin/bash并给执行权限，要么在crontab里设置SHELL=/bin/bash；另一个是MAILTO，如果不想收到cron任务输出的邮件，可以在crontab里写MAILTO=""。这一行至关重要，特别是任务很多很频繁的机器，不关掉邮件通知，很容易积累大量垃圾邮件文件。

4. systemd timer：更现代的调度方案

4.1 timer单元怎么组织

如果你已经会用systemctl管理服务，那学systemd timer几乎零成本。它本质上由两个单元组成：一个.timer描述何时触发，一个.service描述真正要做什么。两者可以同名，也可以不同名，但绝大多数情况下我们让它们同名，便于管理。

假设我要创建一个每天凌晨3点执行备份的计时器，先在/etc/systemd/system/下创建backup.service：

[Unit] Description=Backup daily data [Service] Type=oneshot ExecStart=/root/scripts/backup.sh

再创建backup.timer：

[Unit] Description=Timer for daily backup [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target

然后执行：

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

关键点是.service的Type=oneshot，因为定时任务通常执行一次就结束，不是长期驻留。如果漏了这句，有些版本会按默认simple处理，系统认为服务一直处于运行状态，下一次触发时可能行为异常。另外，启动timer只用systemctl start backup.timer或enable --now就行，不要去手动start那个service，除非你想马上测一下。

查看所有timer的状态用systemctl list-timers --all，输出里会有NEXT、LEFT、LAST、PASSED等列，分别表示下次触发时间、剩余时间、上次触发时间、距上次已过去多少。这个命令是考试常考的，因为你要验证“定时器有没有真正生效”。

4.2 OnCalendar表达式与常用写法

timer的触发时间主要由OnCalendar=决定，它支持类似cron的写法，但语法更接近人类语言。常用格式如下：

注意几点：第一，OnCalendar的时间精度默认是秒级，但你在表达式里写整数分钟时，systemd会把它按“指定那一分钟内的某一秒”来处理，不需要精确定义到秒；第二，如果写daily和写*-*-* 00:00效果一样，但前者可读性更好；第三，表达式里支持英文简写星期，如Mon、Tue，也支持范围组合。考试不会考特别刁钻的日历表达式，但你要能看懂Mon *-*-* 09:00这类格式，并能判断它和crontab0 9 * * 1是同一个意思。

在写OnCalendar时容易犯的错是时区。systemd timer默认使用系统本地时区，如果系统时区配置错了，所有定时器都会跟着错。可以用timedatectl检查当前时区，用timedatectl set-timezone Asia/Shanghai（这是举例，具体时区按你的机器环境来）修正。这一点在云服务器上特别常见，因为经常有镜像默认时区不是本地时区。

4.3 Persistent与Monotonic：错过补跑机制

timer比cron强的一个重要点，就是补跑机制。当系统关机时错过的任务，如果cron配置的备份任务当时没运行，开机后cron不会自动补上；而systemd timer里如果加了Persistent=true，它会把错过的时间点记住，开机后补跑一次。实际效果就是，如果你每天都设置了凌晨3点的备份，某天夜里关机了，第二天开机后timer会立即补跑任务。

再看另一类相对时间：OnBootSec和OnUnitActiveSec。这两个不是日历时间，而是单调时间，用来表达“开机后多长时间”或“上次执行后多长时间”。比如：

[Timer] OnBootSec=10min OnUnitActiveSec=1h

意思是开机10分钟后执行一次，之后每隔1小时执行一次。这种写法非常适合做健康检查、缓存清理、临时文件清理这类跟日历没有强关系的任务。OnUnitActiveSec计算的是从service上一次被激活开始算，注意不是从timer触发开始算，而是从service真正启动开始算。考试里如果给你一个service执行耗时10分钟，timer设置OnUnitActiveSec=1h，问你下次执行时间，你要能从“service激活完成时刻”往后推1小时，而不是傻傻按timer触发时间算。

补充一句：timer还可以通过RandomizedDelaySec=设置随机延迟，比如RandomizedDelaySec=300，让触发时间在应有基础上随机延后0到300秒。这个功能在多台机器同时从镜像开机、同时跑同类型任务时特别有用，可以避免“惊群效应”，把负载抖动摊平。

5. anacron与临时文件管理

5.1 anacron为什么存在

如果你第一次看系统的timer列表，可能会发现一个叫anacron.service的东西，或者看到/var/spool/anacron/目录。那anacron是干嘛的？它的核心目标是解决“长期关机后错过的任务要不要补跑”的问题。普通cron服务在机器开机运行时才会按分钟检查，如果机器当时没开，任务就错过了。anacron的理念是：不管错过多久，只要机器再次开机，就把该跑的任务补上。

在RHEL系发行版中，/etc/cron.daily/里面的脚本并不是由crond直接每分钟扫描的，而是由anacron驱动。默认的/etc/anacrontab内容大致是：

period delay job-identifier command 1 5 cron.daily nice run-parts /etc/cron.daily 7 10 cron.weekly nice run-parts /etc/cron.weekly 30 15 cron.monthly nice run-parts /etc/cron.monthly

这段配置的含义是：周期为1天的任务，在anacron开始工作后延迟5分钟执行；周期为7天的任务延迟10分钟执行；周期为30天的任务延迟15分钟执行。job-identifier是任务标识，它对应/var/spool/anacron/下的同名文件，用来记录上一次执行的日期时间。

理解了anacron，你就能解释很多现象：为什么把脚本放进/etc/cron.daily/后，不是每天凌晨0点整执行，而是开机后才延迟5分钟执行？如果你用的是一个不常关机的台式机，这几乎没区别；但在虚拟机、笔记本上，区别很大。如果你想让某个目录脚本按精确的日历时间去执行，建议不要放在man cron.daily里，而是自己写一个独立的systemd timer或crontab。

anacron还有一个细节：它默认只在系统连续开机时间满足一定条件时才真正运行。具体来说，如果系统开机后anacron检查发现上次执行时间距今不足对应周期，就跳过；如果超过周期，就会执行。如果你想手动触发某个错过的任务，比如anacron -u可以更新时间戳，anacron -f可以强制执行。不过这些比较冷门，考试只要知道anacron的定位就够了。

5.2 systemd-tmpfiles清理临时文件

RH134第2章通常还会带一个“临时文件管理”的内容，因为它跟调度是天然搭配的：你调度了一个任务，执行完留下临时文件，总得有机制清理。传统的/tmp目录在系统重启后会被清空，但长期运行的服务器不会频繁重启，于是/tmp可能堆积大量垃圾。systemd提供的方案是systemd-tmpfiles，它按配置文件里的规则定期创建、清理文件或目录。

配置文件放在三个层级：/usr/lib/tmpfiles.d/是发行版自带的默认配置，/run/tmpfiles.d/是运行时生成配置，/etc/tmpfiles.d/是管理员自定义配置。我们可以直接在/etc/tmpfiles.d/下新建文件，比如：

d /var/tmp/mycache 0750 root root 7d

这一行的含义是：确保/var/tmp/mycache目录存在，权限750，属主root:root，超过7天未访问的文件会被清理。字段顺序是Type Path Mode User Group Age Argument。常用的Type有：

• d：确保目录存在，如果不存在就创建。
• D：确保目录存在，并递归清理目录下所有内容。
• f：确保文件存在，如果不存在就创建。
• F：不管文件是否存在，都先创建并写入默认内容；如果存在则清空。
• r/R：递归移除目录（r移除空目录，R移除整个目录树）。
• x/X：在清理过程中排除某些路径。

真正执行清理的是系统定时器systemd-tmpfiles-clean.timer，它默认每天触发一次。如果你想手动验证文件名写没写对，可以用systemd-tmpfiles --create应用创建规则，用systemd-tmpfiles --clean立即执行清理规则。特别注意：--clean会真的删东西，先在测试机上试好，别在生产机上一顿猛删。Age字段可以写成10s、5m、1h、2d、1w等形式，判断时要看文件的修改时间、访问时间还是创建时间，取决于系统计算规则，默认一般是基于mtime。

6. 实操中的问题排查与考试要点

6.1 任务没执行的排查步骤

无论你用at、cron还是systemd timer，都会遇到“明明配置了，为什么没跑”的问题。我的排查顺序一般是固定的，按下面六步走，基本能解决90%的问题。

第一步，确认调度服务本身在运行。cron对应的是crond服务，检查systemctl status crond；systemd timer不需要单独的服务，但你要确认timer单元已经systemctl list-timers能看到。如果服务挂了，配置再对也没用。

第二步，确认任务是否真的被记录了。用crontab -l或atq查看，有时候用户编辑错了文件，改的是/var/spool/cron里别人的文件，这种情况很少见但真的发生过。

第三步，检查系统时间。用date看当前时间，用timedatectl看时区。cron和timer都依赖系统时间，如果你把任务设在02:00，但系统时区是UTC，你实际看到的执行时间可能和本地时间偏差很大。

第四步，看日志。RHEL系发行版中cron任务的执行记录在/var/log/cron，可以用grep CRON /var/log/cron | tail -50查看最新的调度记录。systemd timer相关的执行记录在journal里，用journalctl -u backup.timer和journalctl -u backup.service查看。这一步能最快定位“任务有没有被触发”“命令有没有执行但报错”。

第五步，检查脚本本身。很多任务没跑其实脚本跑是跑了，但失败了。比如脚本没有执行权限、脚本开头没有shebang、脚本里用到的路径在cron的PATH下不存在。如果你是root的crontab调用脚本，建议先用bash -x /root/scripts/xxx.sh手动跑一遍，确认没有语法错误和权限问题，再让人家考虑调度的事。

第六步，检查输出和邮件。如果cron任务执行后有输出，你可以看/var/mail/用户名文件，里面会记录命令执行的STDOUT和STDERR，这对诊断非常有帮助。如果你设置了MAILTO=""，那就没有邮件可看，这时就更需要脚本自己也写日志。

6.2 任务重复执行的常见原因

任务没跑是常见问题，任务跑重复了也是常见问题，而且更难排查。举个例子：你配置了一个每分钟执行的crontab，结果发现实际每分钟执行了两次。这时候要留意是不是同时存在多个副本。比如某个脚本被同时丢进了/etc/cron.daily/和root用户的crontab，或者你在/etc/cron.d/下建了一个文件，系统里又存在一个同名脚本在另一个目录。建议每次新增调度任务前，先查一遍现有配置：

crontab -l ls -l /etc/cron.d/ ls -l /etc/cron.daily/ systemctl list-timers --all

另一个经典重复源是anacron和cron同时指向同一个脚本。如果你把某个脚本放进/etc/cron.daily/，同时又用systemd timer或crontab去执行同一个脚本，同一批任务可能一天跑两次。所以要记住：每天/每周任务，优先选择同一个调度入口，不要多头管理。

6.3 备考速查：at、cron、timer对比表

考试前背命令不如背对比。我整理了一张速查表，把三者最关键的区别列出来，你复习的时候可以反复看：

再补充两个容易考的知识点：第一，cron里星号通配、斜杠步长、逗号枚举、连字符范围这四种表达方式要熟，题里常让你把“每两个小时”写成0 */2 * * *；第二，systemd timer的.service文件名和.timer文件名可以不同名，但如果你用systemctl enable --now启用的是timer，不是service。选择题经常故意混淆这两个概念。

另外，RH134的考试环境通常是命令行终端，没有图形界面辅助。所以不要把希望寄托在什么面板工具上，你只要把at -f、crontab -e、systemctl enable --now xxx.timer、systemd-tmpfiles --clean这几个核心命令练熟，题目基本就稳了。有个小技巧：做实验时把任务的执行动作写成一个简单的写文件命令，比如echo test >> /tmp/test.log，这样验证起来一目了然，比去跑一个复杂脚本方便得多。

我在实际环境里还有一个体会：别把所有调度任务都堆在root的crontab里。正确的做法是给每个业务建一个普通用户，用该用户的crontab或systemd timer去管理自己的任务。好处是权限隔离，出了问题你不至于需要看root的大杂烩配置；而且将来有人离职，你只需要把那个用户相关的timer停掉，不会误伤其他任务。如果你今天刚开始学这一章，我建议你先把at和cron练熟，把crontab的OR逻辑记死，再去研究timer的Persistent和OnCalendar。这几个点通了，RH134第2章的分数基本就拿全了。