为何两台配置相同的树莓派的systemctl定时器生成的MariaDB条目数量不一致？

可能的原因 #

• 网络连接超时导致插入失败：数据库部署在树莓派1上，树莓派1走本地回路连接数据库延迟极低，几乎不会出现超时；树莓派2走局域网连接，网络波动、丢包、数据库瞬时繁忙都可能触发代码里的5秒超时逻辑，直接退出导致本次插入失败，次数积累下来差距就会越来越大。
• systemd timer精度/触发跳过问题：
  1. systemd timer默认AccuracySec精度为1分钟，为了省电会合并临近的定时任务，可能导致部分15秒触发被合并错过，你看到的倒计时正常不代表实际触发频率完全一致。
  2. 如果脚本单次执行时间超过15秒，systemd默认不会并发执行相同服务，下一次触发会直接跳过。树莓派2因为要走网络建立数据库连接，执行耗时本身更长，遇到波动很容易超过15秒导致触发被吞。
• 代码冗余拉长执行耗时：你的dbConnection函数里存在多余的空库连接、重复开闭连接的逻辑，额外增加了网络交互次数，进一步拉长了树莓派2的脚本执行时间，提高了触发被跳过的概率。
• 本地命令执行失败：如果vcgencmd读取温度失败返回空值，且数据库表的temperature字段设置了非空约束，会直接导致插入失败，不过这个概率两台设备应该差不多，不是核心原因。

排查&解决步骤 #

1. 先看树莓派2的错误日志/var/log/TempLogger_error.log，优先确认是不是存在大量数据库连接超时、插入失败的报错，这是最可能的原因。
2. 统计两端服务实际触发次数：执行journalctl -u FanLog.service | grep "Started Lüfter Temperatur Logger Service" | wc -l，对比两台设备的触发次数和数据库内的记录数：
   • 如果触发次数本身差距就大：优化timer配置，在FanLog.timer的[Timer]段添加AccuracySec=1s强制1秒精度，添加Persistent=true避免错过的触发被丢弃。
   • 如果触发次数差不多但数据库记录差距大：就是执行失败的问题，在FanLog.service的[Service]段添加Restart=on-failure、RestartSec=2，失败自动重试；同时优化dbConnection函数，删掉多余的空库连接逻辑，直接连接目标库减少耗时。
3. 排查树莓派2的网络质量：ping树莓派1的IP持续一段时间，确认有没有丢包、高延迟的情况，如果用WiFi可以换成有线连接，或者关闭WiFi省电模式。
4. 检查树莓派2的系统负载：如果负载过高导致脚本执行延迟，可以清理不必要的后台服务。

内容的提问来源于stack exchange，提问作者Miracuru