systemd.timer是现代Linux推荐的定时任务方案，通过.service文件定义任务内容、.timer文件设定执行时间，相比cron具备更优的日志集成、依赖管理、持久化执行、灵活时间表达及资源控制等优势。
在Linux系统里，当我们想让某个任务定时自动跑起来，最先想到的大概就是
cron。但坦白说，对于现代Linux发行版，尤其是那些拥抱
systemd的，
systemd.timer才是更推荐、更强大的选择。它提供了更精细的控制粒度、更好的日志集成以及更可靠的任务执行机制。简单来讲，
systemd.timer通过一对文件——一个定义任务本身的服务单元（
.service）和一个定义何时运行任务的计时器单元（
.timer）——来取代传统的
crontab条目。
解决方案
配置一个
systemd.timer定时任务，核心步骤就两步：定义服务和定义计时器。
-
创建服务单元文件（.service）：这个文件描述了你要执行的具体任务。 假设你的脚本在
/usr/local/bin/my_daily_backup.sh
，并且你希望它以backupuser
的身份运行。 你可以在/etc/systemd/system/
目录下创建一个名为my-daily-backup.service
的文件：# /etc/systemd/system/my-daily-backup.service [Unit] Description=My Daily Backup Script # 确保在网络可用后才尝试运行，如果你的脚本依赖网络 After=network-online.target Wants=network-online.target [Service] # 执行的命令，请使用绝对路径 ExecStart=/usr/local/bin/my_daily_backup.sh # 指定运行任务的用户和组，增强安全性 User=backupuser Group=backupuser # 可选：定义工作目录 WorkingDirectory=/home/backupuser/ # 可选：标准输出和错误输出可以重定向到journald，或者你也可以重定向到文件 StandardOutput=journal StandardError=journal # 如果任务失败，可以配置重启策略，例如：on-failure, always Restart=on-failure # 如果ExecStart是长时间运行的进程，可以设置为forking Type=simple [Install] # 通常服务单元不需要Install段，因为它们由timer单元来“拉起”
-
创建计时器单元文件（.timer）：这个文件定义了
my-daily-backup.service
何时被触发执行。 在/etc/systemd/system/
目录下创建my-daily-backup.timer
文件：# /etc/systemd/system/my-daily-backup.timer [Unit] Description=Runs My Daily Backup Script Daily # 确保在对应的服务单元加载后才激活计时器 Requires=my-daily-backup.service After=my-daily-backup.service [Timer] # 定义定时执行的规则，这里是每天凌晨2点15分 # 语法非常灵活，可以参考 systemd.timer 手册页 OnCalendar=daily # 也可以是：OnCalendar=*-*-* 02:15:00 # 或 OnCalendar=Mon..Fri 02:15:00 （周一到周五） # 如果系统关机时错过了运行时间，在系统启动后立即运行一次 Persistent=true # 允许随机延迟，避免所有定时任务同时启动造成瞬时负载高峰 RandomizedDelaySec=15min # 任务启动的精确度，例如，设置为1分钟意味着任务可能在指定时间前后1分钟内启动 AccuracySec=1min [Install] # 这告诉systemd，当enable这个timer时，它应该被timers.target拉起 WantedBy=timers.target
-
启用并启动计时器： 创建完文件后，需要通知
systemd
重新加载配置，然后启用并启动你的计时器：sudo systemctl daemon-reload sudo systemctl enable my-daily-backup.timer sudo systemctl start my-daily-backup.timer
现在，你的每日备份任务就会在每天凌晨2点15分（或稍有随机延迟）自动运行了。
systemd.timer 相比 cron 有哪些优势？
说实话，我个人觉得
systemd.timer在现代Linux环境里，简直是
cron的全面升级。它不仅仅是能定时跑任务那么简单，而是把定时任务融入了整个
systemd的生态系统，带来了好些
cron望尘莫及的优势。
首先，日志管理。
cron任务的输出经常让人头疼，默认是邮件通知，但很多时候邮件系统没配置好，或者你根本不看邮件，任务跑了没跑好，你可能根本不知道。
systemd.timer则不然，它执行的服务单元的输出会直接集成到
journald里。这意味着你可以用
journalctl -u my-daily-backup.service轻松查看任务的每次执行日志，包括标准输出和错误输出，这简直是调试的福音。
其次，依赖管理。这是
cron几乎没有的概念。如果你有个任务需要网络连接才能跑，
cron可不管，时间到了就执行，网络不通就失败。但
systemd.timer可以通过其服务单元的
After和
Wants指令，指定在某个服务（比如
network-online.target）启动之后再运行，或者在特定文件系统挂载之后才运行。这让任务的可靠性大大提升，避免了因为环境未就绪而导致的失败。
再者，可靠性与持久性。
systemd.timer有个非常棒的
Persistent=true选项。如果你的系统在任务应该执行的时候关机了，或者因为其他原因错过了执行时间，当系统下次启动时，
Persistent=true会确保任务立即执行一次。
cron可没这功能，错过了就错过了，除非你手动补跑。
还有，时间表达的灵活性。
cron的时间表达式虽然强大，但对于一些复杂的场景，比如“每个月最后一个工作日”或者“每隔5分钟，但只在工作时间”，
systemd.timer的
OnCalendar语法提供了更直观和强大的表达能力。它甚至支持基于启动时间（
OnBootSec）或上一次激活时间（
OnUnitActiveSec）的相对定时，这在某些场景下非常有用。
最后，资源控制与安全性。
systemd天然集成了cgroups，你可以通过服务单元对任务的CPU、内存、I/O等资源进行更细粒度的限制。同时，指定
User和
Group运行任务也比
cron的简单用户切换更加灵活和安全，尤其是在多用户或复杂服务环境中。
如何编写一个典型的 systemd.service 和 systemd.timer 单元文件？
嗯，光知道优势还不够，真正动手写的时候，细节才是关键。一个典型的
systemd定时任务通常由一个
.service文件和一个
.timer文件构成。这两个文件通常放在
/etc/systemd/system/目录下，这样它们就是系统级的单元，可以被
systemd管理。
我们来拆解一下它们的结构和常用配置项：
1. .service
单元文件 (定义“做什么”)
这个文件描述了你的定时任务具体要执行什么命令，以及以什么环境运行。
# 文件名示例：/etc/systemd/system/my-cleanup.service [Unit] # 描述这个服务是干什么的，方便识别 Description=My Daily System Cleanup Script # 依赖关系：表示这个服务应该在network-online.target之后启动， # 如果你的脚本需要网络，这是个好习惯。 # After=network-online.target # 如果需要某个特定服务先启动，比如数据库，可以这样： # After=postgresql.service # 如果这个服务是某个timer的“从属”服务，可以这样指明： # PartOf=my-cleanup.timer [Service] # 执行类型，通常用simple，表示ExecStart是主进程 Type=simple # 核心：要执行的命令。务必使用绝对路径！ # 例如：ExecStart=/usr/local/bin/my_cleanup_script.sh # 如果命令带参数，就像这样：ExecStart=/usr/bin/python3 /opt/myapp/script.py --config /etc/myapp/config.ini ExecStart=/bin/bash -c "/usr/local/bin/my_cleanup_script.sh >> /var/log/my_cleanup.log 2>&1" # 指定运行此命令的用户和组，强烈推荐使用非root用户 User=cleanupuser Group=cleanupuser # 任务的工作目录 WorkingDirectory=/tmp # 标准输出和错误输出的处理方式，通常设置为journal，便于通过journalctl查看 StandardOutput=journal StandardError=journal # 如果任务失败（非零退出码），是否重启。on-failure 比较常用。 Restart=on-failure # 重启前等待的时间 RestartSec=5s # 任务执行的超时时间，如果超时会被强制终止 TimeoutStartSec=5min # 限制资源，比如内存 # MemoryMax=100M # CPUQuota=10% # 如果脚本是一个长时间运行的守护进程，需要设置为forking # Type=forking # PIDFile=/var/run/mydaemon.pid [Install] # 如果这个服务是单独启动的，可以定义WantedBy。 # 但对于timer调用的服务，通常不需要这个段，因为它是由timer拉起的。 # WantedBy=multi-user.target
2. .timer
单元文件 (定义“何时做”)
这个文件定义了
systemd何时应该激活对应的
.service单元。
# 文件名示例：/etc/systemd/system/my-cleanup.timer [Unit] # 描述这个计时器是干什么的 Description=Runs My Daily System Cleanup Timer # 依赖关系：确保对应的服务单元已经加载并可用 Requires=my-cleanup.service After=my-cleanup.service [Timer] # 最常用的定时器设置：基于日历时间。语法非常灵活。 # 每天凌晨3点0分执行 OnCalendar=daily # 也可以这样：OnCalendar=*-*-* 03:00:00 # 每周日凌晨1点执行 # OnCalendar=Sun 01:00:00 # 每月1号和15号的下午2点执行 # OnCalendar=*-*-1,15 14:00:00 # 每隔5分钟执行一次（注意：这表示从timer启动时算起，每隔5分钟） # OnCalendar=minutely/5 # 如果系统关机或任务错过执行，在系统启动后立即执行一次。非常重要！ Persistent=true # 随机延迟，防止所有定时任务在同一秒启动，造成瞬时负载峰值 # RandomizedDelaySec=1h # 最多延迟1小时 RandomizedDelaySec=10min # 任务执行的精确度。例如，设置为1分钟，表示任务会在指定时间前后1分钟内启动 AccuracySec=1min # 也可以基于系统启动时间或上一次激活时间来定时 # OnBootSec=10min # 系统启动10分钟后执行一次 # OnUnitActiveSec=1h # 服务上次激活1小时后执行一次 [Install] # 这是让systemd知道如何启用这个timer的。 # timers.target 是所有定时器单元的通用目标。 WantedBy=timers.target
编写这些文件时，记得使用绝对路径，并且给脚本加上执行权限（
chmod +x your_script.sh）。然后别忘了
sudo systemctl daemon-reload，再
enable和
start你的
.timer单元。
调试 systemd.timer 定时任务的常见方法有哪些？
我个人遇到过不少次，任务就是不跑，或者跑了但没达到预期，结果发现是路径不对、权限问题，或者时间没设对。调试
systemd.timer任务，其实主要就是利用
systemd自身的工具链。
-
检查单元状态： 这是最基本的，也是第一步。你需要检查你的
.timer
和它对应的.service
单元的状态。systemctl status my-cleanup.timer
：查看计时器是否正在运行，以及它下次计划运行的时间。systemctl status my-cleanup.service
：查看服务单元的最新运行状态，包括是否成功完成，或者是否有错误。
-
查看日志：
systemd
的一大优势就是日志集中管理。journalctl
是你的好朋友。journalctl -u my-cleanup.service
：查看服务单元的所有日志输出，包括你的脚本打印到标准输出和标准错误的信息。这是诊断脚本内部错误的关键。journalctl -u my-cleanup.timer
：查看计时器单元的事件，比如它何时被激活，何时触发了服务单元。- 你还可以加上
-f
（follow）实时查看日志，或者-n 100
（显示最近100行）。
-
手动触发服务： 如果怀疑是脚本本身的问题，而不是定时器的问题，你可以尝试手动启动服务单元，看看它是否能正常运行。
sudo systemctl start my-cleanup.service
：这会立即运行你的服务，你可以观察其输出和日志。
-
列出所有计时器： 想知道系统里所有
systemd.timer
的运行状态和下次执行时间？systemctl list-timers --all
：这个命令会列出所有加载的计时器单元，以及它们的上次激活时间、下次激活时间、是否持久化等等。这对于检查你的OnCalendar
设置是否生效非常有用。
-
语法检查： 有时候，单元文件里一个小小的拼写错误或者格式问题，就能让整个单元无法加载。
sudo systemd-analyze verify /etc/systemd/system/my-cleanup.service
sudo systemd-analyze verify /etc/systemd/system/my-cleanup.timer
这些命令可以帮你检查单元文件的语法是否正确。
-
检查脚本权限和路径： 这是最常见的“低级错误”。
- 确保你的脚本有执行权限：
chmod +x /usr/local/bin/my_cleanup_script.sh
。 - 确保
ExecStart
中使用的所有路径都是绝对路径，并且User
和Group
指定的账户有权限访问这些路径和文件。
- 确保你的脚本有执行权限：
通过这些方法，通常都能定位到
systemd.timer定时任务的问题所在。记住，耐心和细致的日志分析是解决问题的关键。
