自动化运维的第一课 | 时间格式详解 + 实战案例 + 避坑指南

在 Linux 系统中，大量工作是重复性的——同步时间、备份数据、清理日志、系统巡检。手动执行既低效又容易遗忘，定时任务（crond） 就是解决这个问题的标准方案。它就像一个永不忘事的闹钟，按你设定的时间自动执行命令或脚本。

本文将从部署、配置到生产实战，带你彻底掌握这项运维基本功。

一、服务使用的通用流程

在学习任何 Linux 服务之前，先建立一个通用的思维框架。不仅定时任务，后续学习 Nginx、MySQL 等服务都是这套流程：

建立这个习惯后，学任何新服务都不会无从下手。

二、部署定时任务

软件包与服务

• 软件包名：cronie

• 服务进程名：crond

# 检查是否已安装rpm -qa cronie# 查看软件包包含的文件rpm -ql cronie# 检查服务是否运行systemctl status crond

大多数 Linux 发行版默认已安装并启用 crond，一般无需手动安装。

目录结构

用户级 vs 系统级： 日常使用推荐 crontab -e 管理用户级定时任务；/etc/crontab 和 /etc/cron.*/ 属于系统级，了解即可。

三、crontab 命令

crontab 是管理定时任务的核心命令，用于增删改查定时任务规则。

# 查看定时任务$ crontab-lno crontab for root    # 表示当前用户尚未设置定时任务# 编辑定时任务（会打开编辑器）$ crontab-eno crontab for root - using an empty one    # 首次编辑会新建空文件crontab: installing new crontab             # 保存退出后提示更新成功

危险操作：crontab -r 会一次性删除当前用户的所有定时任务，且没有确认提示。建议用 crontab -e 进去手动删除指定行，更安全。

四、时间格式详解

这是定时任务的核心，也是最容易出错的地方。

基本格式

*  *  *  *  *  要执行的命令│ │ │ │ ││ │ │ │ └─── 周几（0-7，0 和 7 都表示周日）│ │ │ └───── 月份（1-12）│ │ └─────── 日期（1-31）│ └───────── 小时（0-23，24小时制）└─────────── 分钟（0-59）

特殊符号

经典示例

# 每天早上 8:3030 08 * * *  CMD# 每天凌晨 0 点00 00 * * *  CMD# 每周六凌晨 0 点00 00 * * 06  CMD# 每天 7 点到 23 点，每 2 小时执行（07, 09, 11, 13, 15, 17, 19, 21, 23）00 07-23/2 * * *  CMD# 每天 23 点到次日 7 点，整点执行00 23,00-07 * * *  CMD# 每月 1 号和 15 号凌晨 3 点00 03 1,15 * *  CMD# 工作日（周一到周五）上午 9 点00 09 * * 1-5  CMD

分钟位置的常见坑：

涉及小时、天、周的定时任务，分钟位置一定要写具体数字（通常写 00），不要留 *。

• * 00 * * * CMD — 凌晨 0 点的每一分钟都执行（0:00, 0:01, ... 0:59，共 60 次）

• 00 00 * * * CMD — 凌晨 0 点只执行一次

这是新手最高频的错误，务必注意。

五、实战案例

案例 1：每 2 分钟同步系统时间

# 同步时间*/2 * * * * /sbin/ntpdate ntp1.aliyun.com >/dev/null 2>&1

调试方法：

1. 先手动执行命令确认可用：/sbin/ntpdate ntp1.aliyun.com

2. 用 date 命令故意改错时间，等待定时任务自动修正

3. 查看日志确认是否运行：tail -f /var/log/cron

注意： 定时任务日志只记录"是否运行了"，不记录"是否运行成功"。要确认结果，需要自己验证（如检查时间是否修正）。

补充： 在 CentOS 7+ / RHEL 8+ 中，推荐使用 chrony 替代 ntpdate 做时间同步，更精准且支持持续校准。

案例 2：每天凌晨 1 点备份 /etc/ 目录

第一步：准备目录和脚本

# 创建备份目录和脚本目录mkdir -p  /backup/mkdir -p  /server/scripts/

第二步：编写备份脚本

# /server/scripts/backup-etc.sh#!/bin/bashtar zcf /backup/etc-$(date +%F_%w).tar.gz /etc/

第三步：手动测试脚本

sh /server/scripts/backup-etc.shls-lh /backup/    # 确认压缩包已生成

第四步：配置定时任务

# 先用每分钟运行进行调试* * * * * /bin/sh /server/scripts/backup-etc.sh >/dev/null 2>&1# 调试通过后改为正式时间：每天凌晨 1 点00 01 * * * /bin/sh /server/scripts/backup-etc.sh >/dev/null 2>&1

最佳实践： 备份任务放在业务低谷期（如凌晨），避免影响在线服务。

案例 3：每天凌晨清理 30 天前的日志

# 清理应用日志00 02 * * * /usr/bin/find /var/log/app/ -type f -name'*.log' -mtime+30 -delete >/dev/null 2>&1

案例 4：每周一早上 9 点发送系统巡检报告

# 执行巡检脚本并将结果发邮件00 09 * * 1 /bin/sh /server/scripts/check-system.sh | mail -s"Weekly System Report" admin@example.com >/dev/null 2>&1

六、定时任务书写规范

生产环境中，定时任务的可维护性和原笔记中的知识同样重要。推荐遵循以下规范：

1. 每条任务必须写注释

# 同步系统时间 by ops at 2024-01-15*/2 * * * * /sbin/ntpdate ntp1.aliyun.com >/dev/null 2>&1# 每天凌晨1点备份 /etc/ 目录 by ops at 2024-01-150001 * * * /bin/sh /server/scripts/backup-etc.sh >/dev/null 2>&1

2. 命令使用绝对路径

定时任务运行时的 PATH 环境变量和登录终端不同，可能找不到命令。

# ❌ 可能找不到命令*/2 * * * * ntpdate ntp1.aliyun.com# ✅ 使用绝对路径*/2 * * * * /sbin/ntpdate ntp1.aliyun.com

用 which 命令查看命令的绝对路径：which ntpdate 输出 /sbin/ntpdate。

3. 将输出重定向到 /dev/null

定时任务的标准输出和错误输出默认会以邮件形式发送给用户，积累多了会占满磁盘。

# 丢弃所有输出*/2 * * * * /sbin/ntpdate ntp1.aliyun.com >/dev/null 2>&1# 如果需要记录日志，重定向到文件*/2 * * * * /sbin/ntpdate ntp1.aliyun.com >> /var/log/ntpdate.log 2>&1

解读 >/dev/null 2>&1：

• >/dev/null — 标准输出丢弃到黑洞

• 2>&1 — 标准错误（2）合并到标准输出（1）的去向，也就是一起丢弃

4. 复杂逻辑写脚本，定时任务只调用脚本

# ✅ 推荐：定时任务调用脚本00 01 * * * /bin/sh /server/scripts/backup-etc.sh >/dev/null 2>&1# ❌ 不推荐：定时任务里写复杂命令00 01 * * * cd /etc && tar zcf /backup/etc-$(date +\%F).tar.gz . && find /backup/ -mtime+7-delete

5. 定时任务中 % 需要转义

在 crontab 中，% 有特殊含义（表示换行）。如果命令中包含 %，必须用 \% 转义。

# ❌ 错误：% 会被解释为换行00 01 * * * tar zcf /backup/etc-$(date +%F).tar.gz /etc/# ✅ 正确：转义 %00 01 * * * tar zcf /backup/etc-$(date +\%F).tar.gz /etc/# ✅ 更推荐：把命令写在脚本里，脚本中不需要转义00 01 * * * /bin/sh /server/scripts/backup-etc.sh >/dev/null 2>&1

七、调试与排障

查看定时任务日志

# 实时查看定时任务执行记录tail -f  /var/log/cron

日志示例：

Jan 15 01:00:01 server CROND[16436]: (root) CMD (/bin/sh /server/scripts/backup-etc.sh >/dev/null 2>&1)

日志只告诉你"任务跑了没有"，不告诉你"跑成功了没有"。验证成功需要检查实际结果（压缩包是否存在、时间是否同步等）。

调试四步法

1. 手动执行命令/脚本，确认能正常运行

2. 定时任务先设为每分钟（* * * * *），快速验证

3. 查看 /var/log/cron 日志，确认任务被触发

4. 检查实际结果（文件是否生成、数据是否更新），确认后改为正式时间

常见故障排查

八、补充：安全与权限控制

限制哪些用户可以使用 crontab

# /etc/cron.allow — 白名单（只有列出的用户可以使用 crontab）# /etc/cron.deny  — 黑名单（列出的用户禁止使用 crontab）

规则：

• 如果 cron.allow 存在，只有其中列出的用户可以使用，cron.deny 被忽略

• 如果 cron.allow 不存在，则 cron.deny 中的用户被禁止，其余用户可用

• 两个文件都不存在时，默认只有 root 可用（不同发行版策略可能不同）

补充：anacron

anacron 用于处理在系统关机期间错过的定时任务。它不像 crond 要求系统持续运行，适用于非 7x24 运行的机器（如开发机、笔记本）。

# anacron 配置文件cat /etc/anacrontab

补充：systemd timer（现代替代方案）

在较新的 Linux 系统中，systemd timer 可以替代 cron，提供更精细的控制：

# 查看系统中所有 timersystemctl list-timers# timer 单元文件示例：/etc/systemd/system/backup.timer[Unit]Description=Daily backup timer[Timer]OnCalendar=*-*-* 01:00:00Persistent=true[Install]WantedBy=timers.target

优势：依赖管理、日志集成（journalctl）、更灵活的时间表达式、错过任务可补执行。了解即可，crond 仍然是目前最通用的方案。

写在最后

本文覆盖了 crond 定时任务的完整知识链：

• 服务部署与目录结构，建立全局视角

• 时间格式五段式详解 + 四个特殊符号，彻底搞懂调度规则

• 同步时间、自动备份、日志清理、系统巡检四个生产级案例

• 五条书写规范（注释、绝对路径、重定向、脚本化、% 转义）

• 调试四步法 + 常见故障排查表，遇到问题不慌

• 安全控制、anacron、systemd timer 等扩展知识

这是自动化运维的第一课，也是最基础的一课。 接下来还有更多实战内容：

• Shell 脚本编程 — 让定时任务执行的内容更强大

• 日志管理与 logrotate — 管好系统产生的海量日志

• 监控与告警 — 定时任务跑没跑成功，让系统自己告诉你

关注本公众号，运维系列持续更新，每篇都是拿来就能用的干货。

觉得有用？转发给你的运维/开发同事，一起告别重复劳动。