演示前一天下午，我打开 3liantieerji 的实时数据页，图表区域一片空白。不是"数据偏少"，是彻底没有。翻项目留痕：实时数据走 IoTDB（116 那台）的root.shaojie点位，靠本机一个sim_realtime_daemon.py守护进程每分钟灌一次模拟值。这个进程大概率三天前就死了，只是没人盯。
先确认断档时刻，别盲目重启
没有直接去重启进程。第一步是确认数据到底断在哪。
ping 116，通，排除网络问题。- 连上 IoTDB，查
root.shaojie.SM1最新数据时间戳。 - 点位全空。再查
root.shaojie下所有序列，看最后一条数据停在什么时候。
结果出来：当前时间 2026-10-26 14:10，最后数据时间戳1792724940000，换算完是 10-23 上午 11 点多。差了近三天。本机一关机或终端一关，守护就没了——它从来不是 systemd 服务，只是"手动 nohup 跑着"。
实时页查的是"最近几小时"窗口，窗口内一个点都没有，自然空白。
补灌脚本：跨天 + 日累计 0 点清零
确认断档后，直接重启守护只能补上"此刻往后"，10-23 到 10-26 这三天是洞。必须写一个补灌脚本。
关键约束是语义对齐：守护进程写日累计值时，每天 0 点会清零重新开始。补灌脚本必须复现这个行为，否则 10-24、10-25 两天的日累计值会接在 10-23 的尾部，数据全错。
脚本逻辑：
- 按天遍历断档区间，每天 0:00 起算，日累计从 0 开始。
- 每分钟生成 34 个序列的值，写入 IoTDB。
- 写入前做幂等检查，避免重跑时产生重复点。
执行结果：34 序列 × 153,068 个点，覆盖 10-23 11:11 到当前，耗时约 4 分钟。补完后重启守护进程，实时页立刻有数据了。
把守护迁到 134：CentOS 7 上的四个坑
本机跑守护的隐患是"演示那天我电脑没开"。决定把守护迁到服务器 134，用 systemd 常驻。但 134 上没装 Python，开始装就一路踩坑。
坑 1：yum 源失效。134 是 CentOS 7，EOL 后官方 yum 源全挂了，yum install python3直接报Cannot find a valid baseurl。无解，只能绕。
坑 2：Git Bash 把 URL 参数搞坏。改用 Miniconda（清华镜像可达）。在 Git Bash 里执行curl -o miniconda.sh https://mirrors.tuna.tsinghua.edu.cn/...，结果 Git Bash 把 URL 里的&和/做了路径转换（mangle），下载到本地是个 404 HTML 页面。解法：把下载命令写成独立.sh脚本，scp上去再执行，绕开 Git Bash 的转换层。
坑 3：sftp 通道抽风。本想用 sftp 上传脚本，sftp 连上后put文件时反复超时——这是那个网络环境的老毛病。最终改用 base64 内联：本地base64 -w0 script.sh | ssh 134 "base64 -d | bash"，一条命令搞定，不经过 sftp 通道。
坑 4：glibc 太老，pandas 装不上。Miniconda 装好后conda install pandas，pandas 在 134 的 glibc 2.17 上找不到兼容的预编译 wheel，回退到源码编译，而 134 没装 gcc，直接失败。临时方案：守护脚本本身不依赖 pandas，用pymysql/requests替代数据读写，绕过了这个依赖。
最终 134 上跑通了：Miniconda + systemd unit 文件，守护进程开机自启，演示不再依赖我的笔记本。
三条能带走的教训
守护进程从第一天就该是 systemd 服务。"手动 nohup + 记得别关终端"不是方案。哪怕本地开发机，也写个
~/.systemd/user/的 unit，loginctl enable-linger一下，关机不关服务。补灌必须复现原始写入语义。日累计清零、跨天边界、幂等检查——这三样少一个，补出来的数据就是错数据，比没数据更难排查。
CentOS 7 EOL 后装东西，最短路径是 Miniconda + base64 内联。yum 没了，Git Bash 会 mangle URL，sftp 不稳。
base64 -w0 | ssh "base64 -d | bash"一条命令绕过所有中间层，比折腾网络配置快得多。
做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。
这篇里提到的坑，都是真金白银踩出来的。
如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作
——可以在评论区说说你的场景，我看看能不能自动化掉。
