物联网网关为什么需要systemd做物联网网关开发的工程师大多经历过这个场景网关跑着数据采集服务、MQTT转发服务、本地缓存服务用nohup或screen后台启动看起来能跑。但一旦断电重启所有服务全没了得SSH上去手动拉起来。systemd是Linux系统的事实标准init系统Ubuntu/Debian/Raspbian默认安装。它解决三个核心问题开机自启、异常退出自动重启、日志集中管理。对于部署在无人值守环境下的物联网网关这三个能力是刚需不是选配。编写systemd Service单元文件一个物联网网关通常需要管理多个服务。以数据采集服务为例编写service文件# /etc/systemd/system/iot-collector.service [Unit] DescriptionIoT Data Collection Service Documentationhttps://gitee.com/zesso/hardware_tool Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Useriot Groupiot WorkingDirectory/opt/iot/gateway # 启动命令指定配置文件和日志级别 ExecStart/usr/bin/python3 /opt/iot/gateway/collector.py --config /opt/iot/config.yaml --log-level info # 重启策略异常退出5秒后自动重启5分钟内重启超过3次则停止 Restarton-failure RestartSec5s StartLimitBurst3 StartLimitIntervalSec300 # 资源限制防止内存泄漏吃满网关内存 MemoryLimit256M CPUQuota50% # 日志输出到journald StandardOutputjournal StandardErrorjournal SyslogIdentifieriot-collector # 安全加固限制服务权限 NoNewPrivilegestrue ProtectSystemstrict ProtectHometrue PrivateTmptrue ReadWritePaths/opt/iot/data /var/log/iot [Install] WantedBymulti-user.target逐块说明关键配置项。Afternetwork-online.target确保网络就绪后再启动物联网服务依赖网络连接网络没起来就启动等于白等。Wants而非Requires是因为网络偶尔启动慢用Wants不会因为网络超时导致服务启动失败。Restarton-failure只重启非零退出码的情况手动stop不会触发重启。StartLimitBurst3限制5分钟内最多重启3次防止服务反复崩溃重启造成CPU空转。这个配置在实际项目中很重要有一次内存泄漏导致服务每30秒崩溃重启一次没限制的话会一直循环下去。安全加固部分是生产环境必须加的。ProtectSystemstrict让服务只能写指定目录PrivateTmptrue给它独立的/tmp空间。物联网网关经常暴露在公网一旦服务被攻破这些限制能防止攻击者横向渗透。多服务依赖管理一个网关跑多个服务服务之间有依赖关系。数据采集服务先启动MQTT转发服务依赖采集服务的本地MQTT Broker监控服务依赖前两者都正常运行。用systemd的target单元管理这种依赖# /etc/systemd/system/iot-gateway.target [Unit] DescriptionIoT Gateway Service Group Requiresiot-collector.service iot-mqtt-bridge.service iot-monitor.service Afternetwork-online.target [Install] WantedBymulti-user.target# /etc/systemd/system/iot-mqtt-bridge.service [Unit] DescriptionIoT MQTT Bridge Service Afteriot-collector.service Requiresiot-collector.service [Service] Typesimple ExecStart/usr/bin/python3 /opt/iot/gateway/mqtt_bridge.py --config /opt/iot/config.yaml Restarton-failure RestartSec5s StandardOutputjournal StandardErrorjournal [Install] WantedByiot-gateway.target用Requires建立强依赖采集服务挂了MQTT Bridge也会被拉停。这比各服务独立管理要清晰一个服务挂了不会导致下游服务拿着空数据继续跑。日志轮转与集中查看systemd自带journald日志系统不需要额外装logrotate。但默认配置下journald日志会无限增长在存储空间有限的网关上要限制大小# /etc/systemd/journald.conf [Journal] # 日志最大占用100MB SystemMaxUse100M # 单个日志文件最大50MB SystemMaxFileSize50M # 日志保留7天 MaxRetentionSec7day # 日志转发到syslog可选用于集中日志收集 ForwardToSyslogyes查看特定服务的日志用journalctl按时间和优先级过滤# 查看数据采集服务最近1小时日志journalctl-uiot-collector.service--since1 hour ago# 只看错误级别以上的日志journalctl-uiot-collector.service-perr--sincetoday# 实时跟踪日志输出journalctl-uiot-collector.service-f# 查看某次崩溃前后的完整日志journalctl-uiot-collector.service-b-1--no-pager-b -1看上一次启动的日志排查断电导致的崩溃特别有用。网关断电重启后先看上次启动最后的日志往往能直接定位问题原因。看门狗机制systemd的Restart只能处理进程退出的情况但如果进程假死卡在死循环但不退出Restart不会触发。这种需要看门狗机制。systemd原生支持WatchdogSec# 在service文件中添加 [Service] WatchdogSec30s NotifyAccessmain服务代码里需要定期调用sd_notify告诉systemd我还活着#!/usr/bin/env python3importsdnotifyimporttimeimportsignalimportsysclassGatewayService:def__init__(self):self.runningTrueself.notifiersdnotify.SystemdNotifier()signal.signal(signal.SIGTERM,self._handle_signal)signal.signal(signal.SIGINT,self._handle_signal)def_handle_signal(self,signum,frame):self.runningFalsedefrun(self):# 通知systemd服务已启动self.notifier.notify(READY1)last_heartbeat0whileself.running:nowtime.time()# 每10秒发一次心跳ifnow-last_heartbeat10:self.notifier.notify(WATCHDOG1)last_heartbeatnow# 业务逻辑采集数据、转发消息try:self.collect_and_forward()exceptExceptionase:print(fError:{e},filesys.stderr)# 通知systemd服务状态异常self.notifier.notify(fSTATUSError:{e})time.sleep(1)# 通知systemd服务正在停止self.notifier.notify(STOPPING1)defcollect_and_forward(self):# 实际的数据采集和转发逻辑passif__name____main__:GatewayService().run()WatchdogSec30s表示30秒内没收到心跳就判定服务卡死systemd会强制重启。代码里每10秒发一次心跳留足余量。如果业务逻辑卡在某个死循环心跳发不出去30秒后systemd自动杀掉重启。部署在远程网关上的服务日常运维调试是个痛点。虎王科技开源的随身WiFi硬件调试工具在做通信模组调试时用Web界面远程管理同样的思路也适用于网关服务的远程监控。Gitee上开源做物联网网关运维的可以参考它的Web管理界面设计思路。systemd管理物联网网关的核心是把启动顺序、异常恢复和日志三件事配置好。觉得这些配置项有用的同学收藏一下后续会更新systemd定时器替代cron做定时任务、以及Prometheus监控systemd服务状态的实战内容关注了不漏更新。