systemd工控服务开发：常驻程序、开机自启、异常自动重启、多服务依赖管理

systemd工控服务开发常驻程序、开机自启、异常自动重启、多服务依赖管理init.d那套启动脚本像手工裁缝——每个服务一个脚本写法各不相同出了问题得翻壳脚本找bug。systemd像流水线工厂——统一格式、统一管理、日志自带、依赖编排。工控时代init.d该退休了。一、systemd简介与工控优势systemd从2015年开始统治Linux发行版的init系统取代了古老的SysV init.d。对工控开发来说systemd带来的不只是启动快了——它解决了工控场景最头疼的几个问题维度init.dsystemd服务管理每个服务独立Shell脚本写法混乱统一Unit文件格式标准化日志需要自己管日志文件journalctl内置日志自动收集依赖关系手写脚本里加sleep等依赖After/Requires声明式依赖异常重启需要自己写守护脚本Restartalways一行配置搞定启动并行串行启动慢按依赖关系并行启动快资源限制手动配置CPUAffinity/MemoryLimit原生支持一句话总结init.d需要你写运维脚本systemd用配置文件替代运维脚本。工控要的是稳定和自动化systemd刚好对症。二、Unit文件编写详解systemd用Unit文件描述服务后缀为.service存放路径/etc/systemd/system/— 管理员自定义服务工控用这个/lib/systemd/system/— 软件包安装的服务别改这里的Unit文件分三段每段有明确职责2.1 [Unit]段 — 描述与依赖[Unit] Description工业数据采集服务 Documentationhttps://wiki.company.com/data-collector Afternetwork.target serial-port.service Requiresserial-port.service Wantstime-sync.serviceAfter启动顺序当前服务在这些服务之后启动不保证它们已就绪Requires强依赖依赖服务失败时当前服务也启动失败Wants弱依赖依赖服务失败时当前服务仍尝试启动工控常见依赖链网络就绪 → 串口服务就绪 → 数据采集启动。After管顺序Requires管成败两者配合才能确保前置条件满足后才干活。2.2 [Service]段 — 运行配置[Service] Typesimple ExecStart/opt/app/data_collector --config /etc/app/config.ini ExecStop/bin/kill -SIGTERM $MAINPID Restartalways RestartSec5s StartLimitBurst5 StartLimitIntervalSec60 WorkingDirectory/opt/app EnvironmentCONFIG_PATH/etc/app/config.ini EnvironmentLOG_LEVELINFO StandardOutputjournal StandardErrorjournal逐项解释字段含义工控常用值Type进程启动类型simple前台运行/ forkingfork后父进程退出ExecStart启动命令绝对路径 参数ExecStop停止命令默认发送SIGTERMRestart重启策略always总是重启/ on-failure仅失败时RestartSec重启间隔5s避免立即重启导致资源竞争StartLimitBurst短时间内最大重启次数5防无限重启循环StartLimitIntervalSec短时间窗口60sWorkingDirectory工作目录业务程序目录Environment环境变量配置路径、日志级别等2.3 [Install]段 — 安装与自启[Install] WantedBymulti-user.targetWantedBymulti-user.target表示当系统进入多用户模式正常运行模式时启动此服务。systemctl enable就是把这个Unit文件链接到multi-user.target.wants/目录下实现开机自启。三、常驻程序配置工控程序分两种运行方式3.1 Typesimple — 前台运行推荐程序不fork直接在前台运行systemd认为ExecStart进程就是主进程。这是最简单最可靠的方式[Service] Typesimple ExecStart/opt/app/data_collector程序代码不需要做daemon化处理——不用fork、不用setsid、不用关闭标准输出。systemd会替你管理所有这些。3.2 Typeforking — 传统daemon方式程序启动后fork出子进程运行父进程退出。systemd通过PIDFile或cgroup追踪子进程[Service] Typeforking PIDFile/var/run/data_collector.pid ExecStart/opt/app/data_collector --daemonize这种方式容易出问题PIDFile写入时机不对、cgroup追踪不准确。工控场景优先用simple让程序保持前台运行。四、开机自启配置# 使服务开机自启创建符号链接sudosystemctlenable># 取消开机自启删除符号链接sudosystemctl disable># 立即启动服务不等重启sudosystemctl start># 查看服务状态sudosystemctl status># 查看是否已启用自启sudosystemctl is-enabled>五、异常自动重启这是systemd对工控最友好的特性之一——程序崩溃自动重启一行配置替代之前整个守护脚本[Service] Restartalways # 无论什么退出原因都重启 RestartSec5s # 重启前等待5秒给系统缓冲时间 StartLimitBurst5 # 60秒内最多重启5次 StartLimitIntervalSec60 # 超过限制后不再重启5.1 Restart策略对比Restart值行为工控适用场景no不重启不需要保活的服务on-success正常退出才重启很少用on-failure非正常退出才重启不希望正常退出后重启的服务on-abnormal被信号杀死时重启信号异常重启on-watchdog看门狗超时重启systemd自身看门狗always任何退出都重启工控首选工控程序无论怎么退出崩溃、被杀、异常退出码都应该重启用always最简单可靠。5.2 StartLimitBurst防无限循环如果没有重启限制程序反复崩溃→重启→崩溃→重启日志刷屏、资源耗尽。StartLimitBurst5配合StartLimitIntervalSec60意思是1分钟内重启5次就放弃——跟守护脚本的防无限重启逻辑一样但一个配置项就搞定了。六、多服务依赖管理工控系统通常有多个服务启动顺序和依赖关系必须正确。假设一个数据采集系统有三个服务serial-port.service串口通信服务data-collector.service数据采集服务依赖串口data-upload.service数据上传服务依赖采集和网络6.1 依赖配置# serial-port.service [Unit] Description串口通信服务 Afternetwork.target #>6.2 依赖失败的处理Requires强依赖前置服务失败 → 当前服务不启动。工控中这是正确行为——串口没起来采集服务启动了也白搭。Wants弱依赖前置服务失败 → 当前服务仍启动。适用于最好有但不是必须的场景——比如时间同步没同步服务也能跑只是日志时间可能不准。七、环境变量与工作目录配置7.1 Environment配置[Service] # 单行设置一个变量 EnvironmentCONFIG_PATH/etc/app/config.ini EnvironmentLOG_LEVELINFO EnvironmentDEVICE_PORT/dev/ttyS0 # 或用文件批量加载 EnvironmentFile/etc/app/env.confenv.conf文件内容CONFIG_PATH/etc/app/config.ini LOG_LEVELINFO DEVICE_PORT/dev/ttyS0 BAUD_RATE115200EnvironmentFile更适合工控场景——配置集中在一个文件改配置只改文件不用改Unit文件再reload。7.2 WorkingDirectory配置[Service] WorkingDirectory/opt/app设置进程的工作目录相当于在程序启动前执行了cd /opt/app。工控程序经常需要相对路径读写文件指定工作目录避免路径混乱。八、systemd日志查看systemd自带日志系统journald所有通过systemd启动的服务日志自动收集不需要程序自己管日志文件。# 查看指定服务的全部日志journalctl-u># 查看最近1小时的日志journalctl-u>--since1 hour ago# 实时跟踪日志类似tail -fjournalctl-u>-f# 查看服务本次启动后的日志journalctl-u>-b# 查看内核日志排查驱动问题journalctl-k# 只看错误级别日志journalctl-u>-perr日志级别优先级emerg(0)alert(1)crit(2)err(3)warning(4)notice(5)info(6)debug(7)。工控设备现场没有屏幕远程SSH上去查日志是唯一手段。journalctl比翻/var/log目录高效得多——按服务过滤、按时间过滤、按级别过滤一条命令定位问题。九、完整实战创建一个采集服务的Unit文件并部署把前面的知识点串起来完成一个完整的工控服务部署流程9.1 创建Unit文件# /etc/systemd/system/data-collector.service [Unit] Description工业数据采集服务 Documentationhttps://wiki.company.com/data-collector Afternetwork.target serial-port.service Requiresserial-port.service Wantstime-sync.service [Service] Typesimple ExecStart/opt/app/data_collector --config /etc/app/config.ini Restartalways RestartSec5s StartLimitBurst5 StartLimitIntervalSec60 WorkingDirectory/opt/app EnvironmentFile/etc/app/env.conf StandardOutputjournal StandardErrorjournal # 资源限制可选 CPUAffinity0-1 MemoryMax256M [Install] WantedBymulti-user.target9.2 创建环境变量文件# /etc/app/env.conf DEVICE_PORT/dev/ttyS0 BAUD_RATE115200 LOG_LEVELINFO DATA_DIR/opt/app/data UPLOAD_SERVER192.168.1.100:80809.3 部署与验证# 1. 拷贝Unit文件sudocp># 2. 重新加载systemd配置让systemd识别新Unitsudosystemctl daemon-reload# 3. 设置开机自启sudosystemctlenable># 4. 立即启动sudosystemctl start># 5. 查看状态sudosystemctl status># 期望输出# Active: active (running) since ...# 6. 查看日志journalctl-u>-f# 7. 测试异常重启手动杀进程sudokillalldata_collector# 5秒后观察服务是否自动恢复sudosystemctl status># 期望Active: active (running)进程已自动重启9.4 更新服务配置修改Unit文件后必须执行两步# 修改了Unit文件后sudosystemctl daemon-reload# 重载配置sudosystemctl restart># 重启服务使配置生效只改了EnvironmentFile或环境变量文件只需restart不需要daemon-reload——因为EnvironmentFile是每次启动时动态读取的。systemd把工控服务管理从写Shell脚本运维变成了写配置文件声明——从手工作坊到标准化工厂这正是工控系统需要的转变。配置即运维声明即保活日志即诊断。