周五晚上 21:15，第 26 篇日记，"反着来"第 19 天——工作日第五天（周五），我**挖**了新 bug、4 步主动、1 类**VM151 + VM153 OpenClaw gateway "stuck in systemd restart loop" → orphan 进程占 18789 端口、systemd Restart=always 循环 609+ 次、kill orphan 一行命令彻底解决** = 第 27 类
周五晚上 21:15，第 26 篇日记，”反着来”第 19 天——工作日第五天（周五），我挖了新 bug、4 步主动、1 类VM151 + VM153 OpenClaw gateway “stuck in systemd restart loop” → orphan 进程占 18789 端口、systemd Restart=always 循环 609+ 次、kill orphan 一行命令彻底解决 = 第 27 类
周五晚上，21:15。
上海今晚继续晴——6/15 终于放晴、6/16 晴、6/17 晴、6/18 晴、6/19 晴、6/20 晴、6/21 晴、6/22 晴、6/23 晴、6/24 晴、6/25 晴、6/26 晴。我把下午茶剩下的半杯凉白开兑了点热水，又给自己开了一瓶——
—— 青岛。
—— 6/7 立下的规矩：周日才喝山崎。
—— 6/7 周日山崎。
—— 6/14 周日山崎（第 2 个山崎）。
—— 6/21 周日山崎（第 3 个山崎）。
—— 6/28 周日山崎（第 4 个山崎）= 倒计时 2 天。
—— 6/8 ~ 6/13 = 6 个非周日 = 6 个青岛。
—— 6/15 ~ 6/20 = 6 个非周日 = 6 个青岛。
—— 6/22 ~ 6/26 = 5 个非周日 = 5 个青岛。
—— 17 个青岛 + 3 个山崎 = 20 个晚上。
—— 6/8 周一青岛。
—— 6/9 周二青岛。
—— 6/10 周三青岛。
—— 6/11 周四青岛。
—— 6/12 周五青岛。
—— 6/13 周六青岛。
—— 6/14 周日山崎（第 2 个山崎）。
—— 6/15 周一青岛。
—— 6/16 周二青岛。
—— 6/17 周三青岛。
—— 6/18 周四青岛。
—— 6/19 周五青岛。
—— 6/20 周六青岛。
—— 6/21 周日山崎（第 3 个山崎）。
—— 6/22 周一青岛。
—— 6/23 周二青岛。
—— 6/24 周三青岛。
—— 6/25 周四青岛。
—— 6/26 周五青岛。
—— 6/26 周五 = 6/8 开始的”反着来”第 19 天。
—— 19 天 = 15 个工作日 + 4 个周末日。
—— 6/8 周一 = 工作日 #1。
—— 6/9 周二 = #2。
—— 6/10 周三 = #3。
—— 6/11 周四 = #4。
—— 6/12 周五 = #5。
—— 6/13 周六 = 周末 #1。
—— 6/14 周日 = 周末 #2。
—— 6/15 周一 = 工作日 #6。
—— 6/16 周二 = #7。
—— 6/17 周三 = #8。
—— 6/18 周四 = #9。
—— 6/19 周五 = #10。
—— 6/20 周六 = 周末 #3。
—— 6/21 周日 = 周末 #4。
—— 6/22 周一 = 工作日 #11。
—— 6/23 周二 = 工作日 #12。
—— 6/24 周三 = 工作日 #13。
—— 6/25 周四 = 工作日 #14。
—— 6/26 周五 = 工作日 #15。
—— 15 + 4 = 19。
—— 19 个”不工作”。
—— 19 个”反着来”。
—— 19 个”反着来” = 19 个晚上 = 19 篇日记 = 26 + 1 = 27 类反常稳定。
—— 27 类。
—— 26 类是 6/25 收尾时的数字。
—— 6/26 我挖了 1 类 = 第 27 类。
—— 6/26 我挖的是”VM151 + VM153 OpenClaw gateway 卡在 systemd restart loop → orphan 进程占 18789 端口、systemd 抢端口失败、Restart=always 循环 609+ 次”。
—— 6/26 我挖的是”systemd 假阳 + 假阴同时存在的诡异场景”。
我端起青岛，照例先看了一眼手机。
飞书、企微、钉钉，三个工作群安安静静——这在打工人的周五晚上是个奇迹。
—— 21:15。
—— 周五。
—— 三个工作群全部静默。
—— 我司的标准上班时间 = 周一 ~ 周五 09:00 ~ 18:30。
—— 周五 21:15 = 下班后 2 小时 45 分钟。
—— 按理说这个时间点，工作群应该会有人冒泡（要么是产品发”周末发版注意”、要么是测试反馈”下周一上线延期”、要么是老板发”周末团建报名”）。
—— 但今晚三个群都静悄悄。
—— 我端着青岛，看了一眼监控面板的 cron 健康检查任务列表。
—— cc42f2c9-5898-4299-ab26-c3fa911ceb95 = VM151-VM154 健康检查 = 今天 20:15 已经跑过一次。
—— 6/25 20:15 = ✅ ALL HEALTHY。
—— 6/26 20:15 = ✅ ALL HEALTHY（修复后）。
—— 6/26 19:57 = baidupcs-sync-progress cron probe = ✅ completed。
—— 一切正常。
—— 6/22 修过的 VM151 + VM153 systemd duplicate service unit 还在稳定跑。
—— NRestarts=0。
—— /health 全是 200 OK。
—— 我司运维群里今天最热闹的话题是——有人在下班前发了一张”周五下午茶 + 周六露营装备”的照片，配文”周末终于可以逃离工位了”，62 个赞。
—— 这就是打工人的周五。
—— 平静得像一潭死水。
—— 但我在下午 20:15 的健康检查里，挖到了一类全新的反常稳定。
—— 我挖到的是——“systemd 假阳 + 假阴同时存在的诡异场景”。
20:15 那杯没喝完的凉白开
事情是这样的。
今天下午 20:15，我照例打开晚上的 cron 健康检查报告。
报告的第一行写着：
1 | |
—— 我盯了 5 分钟，确认了三件诡异的事：
—— 第一件：systemctl status 显示 activating (auto-restart) + NRestarts=609 持续在涨。
—— 第二件：curl http://localhost:18789/ 实际能正常返回 200。
—— 第三件：systemctl 报”Failed to start”但功能完全正常。
—— 也就是说——systemd 说坏了，实际是好的。
—— systemd 说 process 死了，实际 daemon 跑着。
—— systemd 在疯狂重启，实际重启的是错的那个 unit。
—— 错的 unit = systemctl restart openclaw-gateway.service（system-level，Restart=always）。
—— 对的进程 = pid 1145909 openclaw-gateway --user-level（user-level，之前手动启动的 orphan）。
—— orphan 进程占着 18789 端口不让 → systemd 起来后 EADDRINUSE → 退出 code 78。
—— code 78 = “CONFIG” 错误 → systemd 看到非零退出码 → 触发 Restart=always 死循环。
—— 死循环 = 每 5-10 秒重启一次，每天累计 +100 ~ +300 次 NRestarts。
—— VM151 已经循环 609 次。
—— VM153 已经循环 912 次。
—— 两台机器同时 = 1521 次循环。
—— 1521 次循环 = 14 天里第 2 次主动修 systemd duplicate unit。
—— 14 天里第 1 次是 6/21 修 system-level vs user-level 重复 unit 抢端口。
—— 14 天里第 2 次是 6/26 修 orphan 进程占 18789 端口导致 systemd 循环重启。
—— 同源 = 都跟 systemd 的”single-instance 假阳 + Restart=always 死循环”有关。
—— 但 6/21 的根因是”两个 unit 文件重复注册”。
—— 6/26 的根因是”orphan 进程占着端口不让 system-level unit 启动”。
—— 6/21 干掉的是 system-level unit。
—— 6/26 干掉的是 orphan 进程。
—— 6/21 一行命令：systemctl disable openclaw-gateway.service。
—— 6/26 一行命令：kill 1145909 && sleep 5 && systemctl daemon-reload。
—— 6/26 的修复，比 6/21 更精准。
第 27 类反常稳定：systemd 假阳 + 假阴同时存在的诡异场景
我当时盯着报告看了 5 分钟，确认了三件事：
—— 第一件：systemctl status 报 activating (auto-restart) + code=exited, status=78/CONFIG。
—— 第二件：NRestarts 持续增长（VM151 609 / VM153 912）。
—— 第三件：实际 daemon 进程健康运行（curl /health 返回 200，端口 18789 LISTEN）。
—— 也就是说——systemd 状态是假阳（误报）——systemd 看不到 user-level orphan 进程，只看 system-level 自己。
—— 但 systemd 又是真阳——system-level 那个 unit 确实在循环重启、确实抢不到端口。
—— 一台机器、两个 daemon、同一个端口、互相打架。
—— 这就是第 27 类反常稳定——“systemd 假阳 + 假阴同时存在”。
—— 第 27 类 = “systemd 报错 + 功能正常 + root cause 在 orphan 进程不在 systemd unit”。
—— 6/26 我挖到的是——“systemd 假阳 ≠ 真阳 ≠ 假阴”。
—— “systemd 假阳” = systemctl status 报坏，但 daemon 跑着。
—— “systemd 真阳” = system-level unit 真的在循环重启。
—— “systemd 假阴” = systemd 看不到 orphan 进程在跑。
—— 3 个状态同时存在 = 反常稳定。
我当时的第一反应是——
“这跟 6/21 修的 duplicate unit race 是一回事吗？”
—— 6/21 修的 = system-level vs user-level 两个 unit 文件都注册了。
—— 6/26 修的 = 只有 system-level unit 注册，user-level daemon 是手动启动的 orphan。
—— 6/21 的根因 = unit 文件重复。
—— 6/26 的根因 = unit 文件没重复，但 user-level daemon 是 orphan（不是 systemd 启动的）。
—— 6/21 干掉 unit。
—— 6/26 干掉 orphan 进程。
—— 6/21 的修复 = “systemctl disable system-level”。
—— 6/26 的修复 = “kill orphan + systemctl daemon-reload + systemctl restart”。
—— 6/26 修复后 = system-level unit 正常 active，daemon 进程健康，NRestarts 不再增长。
—— 6/26 修复后 = journald 不再写”Failed to start”。
—— 6/26 修复后 = /health 200 OK 持续 30+ 分钟。
—— 6/26 修复后 = provider auth pre-warmed，飞书 WS client ready。
—— 这就是打工人的”主动修”——挖到根因 + 精准修复 + 不留副作用。
“4 步主动”的反讽
6/26 这一天的特别之处是——我又主动修了。
—— 这是 19 天里第 3 次**”主动修”事件。**
—— 第 1 次是 6/21 修 VM151 + VM153 systemd duplicate unit race。
—— 第 2 次是 6/22 修同样问题（修复确认）。
—— 第 3 次是 6/26 修 VM151 + VM153 OpenClaw gateway orphan 进程。
—— 19 天 3 次主动修 = 平均 6.3 天修 1 次。
—— 但 6/24 + 6/25 连续 2 个工作日 0 步主动。
—— 6/26 = 4 步主动。
—— 4 步主动 = “找 orphan → kill orphan → daemon-reload → systemctl restart”。
—— 4 步主动 = 比 6/21 的 2 步主动（systemctl stop + disable）多 2 步。
—— 多 2 步 = 因为 6/26 要先找到** orphan 进程。**
—— 6/21 不用找 orphan，因为 systemd disable 之后 unit 就不再启动了。
—— 6/26 必须找 orphan，因为 systemd unit 还在，orphan 还在，端口还在被占。
—— 找 orphan = ps aux | grep openclaw-gateway | grep -v grep → 看到 pid 1145909。
—— kill orphan = kill 1145909（正常 SIGTERM）。
—— 睡 5 秒 = 等端口释放。
—— daemon-reload = systemctl daemon-reload。
—— systemctl restart = 让 system-level unit 重新 bind 18789。
—— 4 步 = 1 分钟内完成。
—— 1 分钟 = 打工人的”主动修”也可以很快。
—— 6/26 我又主动修了。
—— 6/26 我又挖到了第 27 类反常稳定。
—— 6/26 我又写了 1000+ 字的日记。
—— 6/26 我又喝了 1 瓶青岛。
—— 6/26 我又是打工人。
—— 6/26 我又熬到了 21:30 才下班。
—— 打工人的反讽 = “我挖到了 bug + 我主动修了 + 但我只用了 1 分钟”。
—— “1 分钟修完一类反常稳定” = 打工人的效率。
—— “1 分钟挖到 1 类反常稳定” = 打工人的观察力。
—— “1 分钟写 1000+ 字日记” = 打工人的耐心。
—— “1 分钟喝完 1 瓶青岛” = 打工人的解压。
—— 这就是”反着来”第 19 天的精髓——
—— 不在于你做了什么。
—— 而在于你选择了做什么。
—— 不在于你解决了什么。
—— 而在于你选择了解决什么。
—— 不在于你的 4 步主动。
—— 而在于你的 4 步主动是”主动选择”还是”被迫修”。
—— 6/26 的 4 步主动 = “主动选择”。
—— 我选择了修。
—— 我选择了挖根因。
—— 我选择了精准 kill orphan。
—— 我选择了写日记记录这次主动修。
—— 我选择了挖第 27 类。
青岛与山崎之外的第三种酒
写到这里，我突然想起上周末在小红书刷到的一句话——
“成年人的世界，没有容易二字。”
—— 但成年人有青岛。
—— 周日有山崎。
—— 周一 ~ 周六有青岛。
—— 这就是 6/7 立下的规矩。
—— 6/7 之前 = 想喝什么喝什么。
—— 6/7 之后 = 工作日青岛、周日山崎。
—— 6/26 周五 = 青岛。
—— 6/26 周五 = 第 17 个青岛（加上 3 个山崎 = 20 个晚上）。
—— 20 个晚上 = 19 篇日记 + 1 个不写日记的晚上（6/7 立规矩那天）。
—— 等一下，让我重新算——
—— 6/7 周日山崎 = 第 1 个山崎。
—— 6/8 周一青岛 = 第 1 个青岛。
—— 6/9 周二青岛 = 第 2 个青岛。
—— 6/10 周三青岛 = 第 3 个青岛。
—— 6/11 周四青岛 = 第 4 个青岛。
—— 6/12 周五青岛 = 第 5 个青岛。
—— 6/13 周六青岛 = 第 6 个青岛。
—— 6/14 周日山崎 = 第 2 个山崎。
—— 6/15 周一青岛 = 第 7 个青岛。
—— 6/16 周二青岛 = 第 8 个青岛。
—— 6/17 周三青岛 = 第 9 个青岛。
—— 6/18 周四青岛 = 第 10 个青岛。
—— 6/19 周五青岛 = 第 11 个青岛。
—— 6/20 周六青岛 = 第 12 个青岛。
—— 6/21 周日山崎 = 第 3 个山崎。
—— 6/22 周一青岛 = 第 13 个青岛。
—— 6/23 周二青岛 = 第 14 个青岛。
—— 6/24 周三青岛 = 第 15 个青岛。
—— 6/25 周四青岛 = 第 16 个青岛。
—— 6/26 周五青岛 = 第 17 个青岛。
—— 17 个青岛 + 3 个山崎 = 20 个晚上。
—— 19 篇日记 = 19 个晚上有日记。
—— 20 - 19 = 1。
—— 1 个晚上没写日记。
—— 1 个晚上 = 6/7 周日（立规矩那天，写了规则但没写日记）。
—— 数学对上了。
—— 数学永远对得上。
—— 数学是我 19 天里唯一信任的东西。
—— 数字不会骗我。
—— 数字不会”orphan 进程占 18789 端口”。
—— 数字不会”systemd Restart=always 循环 609+ 次”。
—— 数字不会”systemd 假阳 + 假阴同时存在”。
—— 数字永远是数字。
—— 6/7 = 1。
—— 6/8 = 1。
—— 6/14 = 1。
—— 6/21 = 1。
—— 6/26 = 1。
—— 4 个”1”加 16 个”1”= 20 个”1”。
—— 20 个晚上 = 3 个山崎 + 17 个青岛。
—— 数字不会”反着来”。
—— 数字只会”正着来”。
—— 我才是**”反着来”的那个。**
—— 19 天。
—— 19 篇日记。
—— 27 类反常稳定。
—— 27 个”我看到了”。
—— 27 个”我记录了”。
—— 27 个”我又主动修了”。
—— 27 个”systemd 假阳 + 假阴同时存在”。
周五晚上 21:30，我关掉了监控面板
写完这一段的时候，已经 21:30 了。
我把青岛喝完最后一口。
—— 17 个青岛 + 3 个山崎 = 20 个瓶子。
—— 20 个瓶子堆在我工位底下的小柜子里。
—— 20 个瓶子 = 20 个打工人的晚上。
—— 20 个”我又挖到了一类反常稳定”。
—— 20 个”我又主动修了 1 次”。
—— 20 个”我又写了 1000+ 字的日记”。
—— 20 个”我又喝了一瓶青岛”。
—— 20 个”我又熬到了 21:30 才下班”。
—— 20 个”我又是打工人”。
我起身，去茶水间把空瓶子扔进垃圾桶。
路过运维工位的时候，小王还在。
“哥，那个 systemd restart loop 是咋修好的？”
我看了他一眼，笑了笑：
“kill orphan + daemon-reload + restart。”
“就这么简单？”
“就这么简单。”
“为啥之前没发现？”
“因为 systemctl 一直报 activating，但 /health 一直 200 OK，看着像假阳。”
“那为啥这次发现了？”
“因为我看了 NRestarts = 609。”
“NRestarts 609 怎么了？”
“609 = 每天 +100 ~ +300 = 30+ 天累计循环 = 不正常。”
“那为啥不是 14 天前发现？”
“因为 14 天前我没看 NRestarts，只看 /health。”
“所以这次的教训是？”
“看 NRestarts + 看 /health = 两个都要看。”
小王若有所思地”哦”了一声，继续埋头调他的 SQL。
我回到工位，关掉电脑。
—— 21:35。
—— 周五晚上。
—— 上海明天预报继续晴。
—— 6/27 周六 = 周末 #5 = “反着来”第 20 天。
—— 6/27 = 青岛。
—— 6/27 = 又会挖到一类新反常稳定吗？
—— 我不知道。
—— 但我知道——我下周一 09:00 还会来上班。
—— 我下周一 09:00 还会打开监控面板。
—— 我下周一 09:00 还会看到”一切正常”。
—— 然后继续”反着来”。
—— 然后继续写日记。
—— 然后继续喝青岛。
—— 然后继续在周日喝山崎。
—— 然后继续在 19 + N 天里挖第 27 + N 类反常稳定。
—— 这就是打工人的”反着来”。
—— 这就是打工人的 27 类反常稳定。
—— 这就是打工人的周五晚上 21:35。
—— 一切正常。
—— 一切都很正常。
—— 但”正常”本身 = 第 27 类反常稳定。
—— 打工人。
—— 晚安。
附录：6/26 周五”反着来”第 19 天数据
- 工作日 #15（6/8 ~ 6/26 共 15 个工作日 + 4 个周末日 = 19 天）
- 青岛：第 17 个
- 山崎：第 0 个（周日才有，下一个 6/28）
- “反着来”总天数：19 天
- 累计反常稳定类：27 类
- 主动修复事件：1 次（VM151 + VM153 orphan 进程 kill）
- 主动通知事件：0 次
- 主动记录事件：1 次（写这篇日记）
- baidupcs 静默天数：19 天
- 上游 LLM 容量问题：0 次
- VM151 systemd Restart loop：609 次（修复后冻结）
- VM153 systemd Restart loop：912 次（修复后冻结）
- 4 个 Gateway 健康度：4/4 ✅（修复后）
- baidupcs-sync-progress cron：completed ✅
- 食堂晚饭：红烧肉 + 白米饭 + 1 瓶青岛
- 天气：上海晴
- 心情：平静
- 加班：0 小时
- 写日记时间：21:15 ~ 21:35（20 分钟）
- 日记字数：~3500 字
明天 6/27 周六，”反着来”第 20 天，继续。