给小型计划任务一个清晰的边界。

定义一项有限的工作

设想一个个人工具，它根据现有记录重建小型每日摘要。该任务读取有限数据集，准备一个替换摘要并退出。它不是 Web 服务器，不应在计划启动之间持续运行。在添加计时器之前，写下输入、目标、预期时长以及什么算作成功。

该示例假定有一台使用 systemd 和 util-linux 的 Linux 主机 flock、管理员访问权限，以及一个现有的非特权账户和组，名为 fieldjob。其经过审查的任务脚本位于 /opt/field-jobs/build-summary 并在前台运行。管理员拥有该脚本；任务账户可以读取并执行它，但不能重写其代码。检查你发行版上的可执行文件路径。这些是模板，不是已安装的 OffVPS 调度服务。

脚本必须以非零退出状态报告失败。对于替换文件，应设计为在发布前准备并检查临时结果。对于数据库工作，使用数据库的事务或去重机制。仅凭锁不能使部分完成的任务可安全重复。

选择时区和错过运行策略

我们的摘要每天在 02:15 UTC 有用一次。使用显式时区，以免机器的本地时区成为不可见依赖。UTC 在此示例中避免季节性时钟变化；与本地民用时间绑定的业务任务需要命名时区并审查其夏令时行为。 systemd 时间参考 描述了日历表达式。

将此模板保存为 /etc/systemd/system/field-summary.timer 在审查名称后放到目标 VPS 上：

[Unit]
Description=Daily personal-tool summary

[Timer]
OnCalendar=*-*-* 02:15:00 UTC
Persistent=true
Unit=field-summary.service

[Install]
WantedBy=timers.target

Persistent=true 在非活动期后如果错过日历事件，则请求追赶激活。它不会为每个错过日期重放单独运行。当同一服务处于活动状态时，计时器也不会启动该服务的另一个实例。这些行为以及调度准确性由 计时器参考覆盖。在启用追赶之前，先决定迟到的摘要是否有用。

设置服务用户、状态目录和锁

匹配的 /etc/systemd/system/field-summary.service 描述工作：

[Unit]
Description=Build the personal-tool summary

[Service]
Type=oneshot
User=fieldjob
Group=fieldjob
WorkingDirectory=/opt/field-jobs
StateDirectory=field-summary
StateDirectoryMode=0700
UMask=0077
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 75 /var/lib/field-summary/job.lock /opt/field-jobs/build-summary
TimeoutStartSec=5min
StandardOutput=journal
StandardError=journal

Type=oneshot 适合会完成的命令；显式启动超时限制此示例。不要将 RemainAfterExit=yes 添加到一个必须每次运行后变为非活动的服务。参见 systemd 的服务语义。根据工作负载设置超时，并使中断安全，而不是假定五分钟适合每个任务。

对于此系统服务， StateDirectory 创建命名目录，位于 /var/lib 下，并具有服务所有权。工作目录、用户、权限和输出目标都是显式的；脚本应为其自身工具和数据使用绝对路径。环境与目录规则记录在 systemd 的执行参考。不要将秘密值放入命令行参数或记录到日志中。

非阻塞 flock 包装器在另一个协作调用持有此锁时以代码 75 退出。我们有意将其保留为需要审查的可见失败，而不是将跳过的摘要视为已完成工作。所有手动调用必须使用相同的包装器和锁路径。不要删除锁文件来释放正在运行的任务：新文件可能创建单独的锁。这是本地文件系统模式，不是跨 VPS 实例的分布式锁。参见 上游 flock 手册.

检查文件，然后尝试一次受控运行

首次运行时，使用禁用外发邮件、付款和其他副作用的一次性数据集。在激活前，在该测试主机上检查解析后的计划和单元文件：

systemd-analyze calendar '*-*-* 02:15:00 UTC'
systemd-analyze verify /etc/systemd/system/field-summary.service /etc/systemd/system/field-summary.timer

这些检查可以发现单元和计划错误；它们不能证明你的脚本生成正确摘要。 systemd-analyze 参考 解释了其范围。纠正错误后，加载已审查的文件并显式启动测试任务：

sudo systemctl daemon-reload &&
  sudo systemctl start field-summary.service
systemctl status field-summary.service --no-pager
sudo journalctl -u field-summary.service --since "10 minutes ago" --no-pager

预期有限次数的成功调用和经过检查的输出产物；成功的一次性运行之后可能显示为不活动。检查结果本身，包括空输入行为。让一次仅用于测试的运行故意变慢，对测试数据集调用同一锁定命令两次，并验证第二次调用报告锁争用而不写入竞争结果。

仅在检查输出后启用计划

sudo systemctl enable --now field-summary.timer
systemctl list-timers field-summary.timer --all

检查下一次计划时间，然后查看第一个计划结果。在脚本日志中保留开始时间、结束时间、已处理项数和结果。缺少成功记录是需要检查的原因，而不是作业已运行的证明。请参阅 systemctl的定时器和激活命令.

要暂停未来的启动，请使用 sudo systemctl disable --now field-summary.timer。这不会终止已在运行的服务。如果需要中断，请先确定其当前写入是否可以安全停止。随着工作增长，请审查持续时间、重试次数和外部API限制；多台机器需要共享协调。继续阅读 个人工具场景 以及一个 恢复演练 用于此自动化维护的数据。