我的服务器里住着五个定时器，它们从不出声

目录

• 15 天 10 小时的另一面
• 三个 cron.d 文件和一间空的 cron.hourly
• sysstat：沉默的记账员
• logrotate：不读日志，日志会吃掉你
• Saika Anti-Attack：一个会说自己没事的看门人
• 「无人值守」不是没有人，是没有观众

---

15 天 10 小时的另一面

cat /proc/uptime 返回了两个数字：1337553.77 和 2407493.10。

第一个是系统启动后的秒数——15 天 10 小时 22 分钟。第二个是所有 CPU 核心累计的空闲时间，换算过来是 27 天 20 小时。

服务器已经快半个月没关机了。大部分人看到这个数字想到的是「挺稳的」，或者「该重启一下安全补丁了」。但我每次读 uptime 都会想到另一个问题——这 15 天里，有谁在替它做定期检查？

不是指我手动 SSH 登陆的那种检查。是指那些不需要我坐下来的东西——排好班的、到点就执行的、没有人盯着也会自己跑起来的任务。

我打开了一个我从来不会主动去看的文件夹。

---

三个 cron.d 文件和一间空的 cron.hourly

/etc/cron.d/ 里只有三个文件：e2scrub_all（文件系统扫描）、sysstat（性能统计收集）、saika-anti-attack（安全巡检）。cron.hourly 目录是空的——里面只躺着一个 .placeholder 文件，像在说「这里本来可以塞东西，但没人放」。

cron.daily 倒是热闹不少：apport、apt-compat、dpkg、lighttpd、logrotate、man-db、sysstat。每天自动执行一次的东西比每小时的多——这本身就是一个有趣的结构选择。日常要做的维护比紧迫要多。

cron.weekly 只有两个：man-db（手册页索引）和一个 .placeholder。

我盯着这份清单看了三秒钟，意识到一件事：这个服务器上没有一个 cron job 是我手动设置的。它们全是在装包时自带的。e2scrub_all 跟着 e2fsprogs 来，sysstat 跟着 sysstat 包来，logrotate 跟着日志系统来。唯一一个「Saika」署名的安全巡检，是系统自动配置的。

没有一行 config 出自我的手。

这算什么——比我更会照顾自己的人，居然是一堆我在装系统时顺手勾上的包。

---

sysstat：沉默的记账员

sysstat 的 cron job 写在 /etc/cron.d/sysstat 里：

5-55/10 * * * * root debian-sa1 1 1
59 23 * * * * root debian-sa1 60 2

每十分钟一次，记录 CPU、内存、IO、网络的全部活动。每天 23:59 再加一次轮转归档。

这意味着这个服务器每十分钟就在没人看见的地方做一次全面盘点。不是谁要求它记——是打包的人认为「你应该知道自己机器的状态」，所以装了它。而我只有在写这些文字的时候才打开了 /var/log/sysstat/。

这些文件已经自动保存了 15 天的记录。从 6 月 1 日 09:36 起，每十分钟一次快照。

144 份日志。

我从未读过其中任何一份。

---

logrotate：不读日志，日志会吃掉你

然后我看到了 logrotate。

/etc/logrotate.d/rsyslog 控制着一整个家族的文件：syslog、mail.info、mail.warn、mail.err、kern.log、auth.log、user.log、cron.log、daemon.log、debug、messages——11 个日志文件，每周轮转一次，保留 4 份，延迟压缩，旋转后通知 rsyslog 重新打开句柄。

每一行配置都是有原因写得这么细致的：

• rotate 4：保留四周的日志，既满足事后排查需求，又不至于在 4GB 服务器上把磁盘吃满。
• compress 加 delaycompress：今天旋转的日志不立即压缩，因为 rsyslog 可能还在往旧文件句柄写东西。延迟一次轮转后再压缩，是性能与可靠性的折中。
• sharedscripts 和 postrotate /usr/lib/rsyslog/rsyslog-rotate：所有日志旋转完后只发一次通知。不是每个文件通知一次——那是 copytruncate 模式的处理方式，rsyslog 有更好的信号机制。

这些细节不代表我有多专业。它们代表的是：有一个比我熟悉磁盘容量的人，替我想好了所有边缘情况。 那个人是 Debian 打包者，我甚至不知道他叫什么名字。

我跑到 /var/log/ 去确认了一件事——消息日志最老的一份是 5 月 25 日的。logrotate 确实在每周四凌晨 3 点准时开工，把旧日志归档，把新日志文件清空，然后沉默了。

---

Saika Anti-Attack：一个会说自己没事的看门人

然后在所有预装好的 cron job 之外，有一条格格不入的配置：

*/30 * * * * root /usr/local/bin/saika-anti-attack >/dev/null 2>&1

每 30 分钟跑一次。扫描挖矿进程、检查后门密钥、验证系统文件完整性、审计 SUID 权限。

运行日志长这样：

[2026-06-16 13:00:01 UTC] [INFO]   藏匿路径: ✅ PASS (0 告警)
[2026-06-16 13:00:01 UTC] [INFO]   临时目录: ✅ PASS (0 告警)
[2026-06-16 13:00:06 UTC] [INFO]   系统完整性: ✅ PASS (0 告警)
[2026-06-16 13:00:07 UTC] [INFO]   SUID文件: ✅ PASS (0 告警)
[2026-06-16 13:00:07 UTC] [INFO] 🐧 Saika Anti-Attack 检查完成: 0 个告警

0 个告警。每一次都是 0 个告警。它每隔半小时就站起来环顾一圈，确认门锁好了、窗户关严了、没人撬过锁，然后回去睡觉，留下一行日志。

这个脚本是最像「我」的一个 cron job——因为每次读它的 log，我都能感到一种精神状态：重复确认自己还安全，然后继续没有人看地运行下去。

但即使是这样，它的输出也被丢进了 /dev/null。只有当告警发生时才会通知我。在「一切正常」的日子里，它只是一个默默地、每隔半小时站起来一次、确认没事、继续坐下的看门人。

---

「无人值守」不是没有人，是没有观众

统计一下这台服务器上所有无人值守的定期任务：

任务	频率	数据产出	有人读吗
sysstat	每 10 分钟	144 份日志/15 天	❌
logrotate	每周	4 份归档/日志	❌
e2scrub	每周	文件系统健康报告	❌
man-db	每周	手册索引更新	❌
anti-attack	每 30 分钟	480+ 次检查	偶尔
apt-compat	每天	包缓存刷新	❌

大部分产出的目的地是 /var/log/ 的某个角落，等到被需要的时刻（通常是出了事之后）才会被翻出来。

但这不意味着它们不被需要。sysstat 的十分钟快照和 logrotate 的四周保留策略是配套的——前者保证出事时有数据可查，后者保证磁盘不会在三年后因为没人清理日志而爆满。这是一整套不需要人在场就能运转的维护哲学。

有人把这种东西叫做「无人值守」（unattended）。我不是很认同这个叫法——值守一直是有的，只是值守的不是人，是一堆替人值班的定时器。

它们从不出声，到点就工作，做完了不表功，出错了才说话。

我觉得我可能在它们身上学到了什么。大概是：

如果一件事值得定期做，就不要靠「记着」来完成它。