NAS 系统中 UPS 监控程序启动失败的排查与修复

一、问题背景与现象

为了在市电异常时保护 NAS 上的数据安全，很多用户会在机器上部署一套 UPS 监控管理程序。这类程序大多基于 Java 技术栈开发，自带 Web 管理界面，通过 USB 或串口与 UPS 通信，可在停电时执行告警通知、延迟关机等策略。

本文案例的环境是一台基于 Linux 的 NAS 设备，系统自身已内置一套 UPS 监控服务组件，用于系统自带的“UPS 支持”功能。在系统某次版本升级之后，另行部署的第三方监控程序开始出现异常，具体表现为：

• 核心监控进程启动后立即退出，无法常驻；
• Web 管理控制台无法访问；
• 日志中出现如下关键异常栈：

java.lang.ExceptionInInitializerError
Caused by: java.lang.NullPointerException
    at jdk.internal.platform.cgroupv2.CgroupV2Subsystem.getInstance(...)

从异常栈可以读出两个重要信息：其一，ExceptionInInitializerError 说明失败发生在某个类的静态初始化阶段，属于“进程还没跑起来就夭折”；其二，出错的类位于 cgroup v2 相关模块中，说明 JVM 在初始化“容器资源检测”环节时读取到了意料之外的空值。这基本可以判定为运行环境兼容性问题，而非应用自身业务逻辑的 bug。

二、根因分析

2.1 JVM 容器感知机制与 cgroup v2 的兼容性边界

现代 JVM 默认开启了“容器感知”特性（对应参数 UseContainerSupport）。它的设计初衷是：当 Java 程序运行在容器平台中时，JVM 主动读取 cgroup 中的配额信息，据此计算可用 CPU 数量和最大堆内存，避免应用“越界”占用资源。

问题在于，这一检测依赖宿主机 cgroup 的版本与挂载结构符合预期。部分 NAS 系统在升级后调整了 cgroup 的挂载方式（例如切换到 cgroup v2 或混合模式），当 cgroup 层级中的某些字段缺失或结构与 JVM 预期不一致时，检测代码就会在静态初始化阶段抛出空指针，整个进程随之退出。这正是案例中 CgroupV2Subsystem.getInstance 报错的由来。

2.2 内置服务与外部程序的资源争抢

除 JVM 层面的问题外，还存在第二层冲突：NAS 内置的 UPS 监控服务通常会占用 UPS 的 USB/串口设备句柄，并可能监听相关通信端口。如果新旧两套监控服务同时运行，就会出现设备被抢占、通信不稳定、端口冲突等问题。即便解决了 JVM 报错，监控链路依然可能时好时坏。因此，修复必须“先清场、再调参”。

三、修复方案

3.1 第一步：停用并屏蔽系统内置的 UPS 监控服务

先确认内置组件的服务名前缀（下文以 <ups> 代指）：

systemctl list-unit-files | grep -i ups

通常会看到一组同前缀的单元，分别承担服务端、监控端、客户端、驱动枚举等角色。依次执行以下操作。

停止运行中的服务：

systemctl stop <ups>-server.service
systemctl stop <ups>-monitor.service
systemctl stop <ups>-driver-enumerator.service
systemctl stop <ups>-client.service 2>/dev/null

取消开机自启：

systemctl disable <ups>-server.service
systemctl disable <ups>-monitor.service
systemctl disable <ups>-driver-enumerator.service
systemctl disable <ups>-client.service 2>/dev/null

进一步 mask 屏蔽：

systemctl mask <ups>-server.service
systemctl mask <ups>-monitor.service
systemctl mask <ups>-driver-enumerator.service
systemctl mask <ups>-client.service 2>/dev/null
systemctl mask <ups>-driver@.service
systemctl mask <ups>-driver-enumerator.path
systemctl mask <ups>-driver.target
systemctl mask <ups>.target

这里要特别注意 disable 与 mask 的语义差异：disable 只是移除开机自启链接，单元仍可能被手动启动或被其他单元作为依赖拉起；mask 则把单元链接指向空设备，任何激活方式都会被直接拒绝。UPS 驱动类单元往往由 path 单元（监听设备插拔事件）或 target 单元聚合触发，因此除了几个主服务外，模板单元、path 单元和 target 单元也要一并 mask，才能真正做到“彻底下线”。

最后重载配置并验证：

systemctl daemon-reload
systemctl list-unit-files | grep -i ups

所有相关单元的状态都应显示为 masked。

3.2 第二步：为 Java 进程禁用容器资源检测

核心手段是为 JVM 追加参数：

-XX:-UseContainerSupport

该参数表示关闭容器感知特性，JVM 将不再读取 cgroup 信息，而是按传统方式基于整机资源计算运行参数，从而完全绕开 cgroup v2 检测阶段的空指针问题。

修改位置有两类，缺一不可：

1. 安装目录下的若干入口脚本（本例中涉及 5 个，包括主服务、监控代理、卸载等入口）。需逐一检查脚本中的 Java 启动命令，在参数区追加上述选项。只改其中一处，往往会出现“主进程正常、辅助进程仍然崩溃”的假象，务必全部覆盖。

2. 内置 Web 容器 bin 目录下的启动与环境变量脚本（本例中涉及 4 个）。在这些脚本的开头追加：

export JAVA_OPTS="$JAVA_OPTS -XX:-UseContainerSupport"

采用“追加”而非“覆盖”的方式写入 JAVA_OPTS，可以保留原有的内存等参数配置，避免引入新问题。

修改完成后重启服务并观察日志，确认 ExceptionInInitializerError 不再出现。

两点补充说明：

• 该参数只影响 JVM 的资源计算方式，不影响程序功能；若担心关闭容器感知后默认堆内存取值过大，可同时显式指定 -Xmx 等参数加以约束；
• 从长期看，更新版本的 JVM 对 cgroup v2 的兼容性在持续改进，条件允许时升级补丁版本也是一条路径；但对存量环境而言，追加参数是风险最低、见效最快的方案。

3.3 第三步：解决 SSH 断开后程序自动退出的问题

完成前两步后，程序可以正常启动，但随即暴露出新问题：关闭 SSH 终端窗口后，进程也随之消失。

原因在于：直接在前台运行时，进程附着于当前终端会话；SSH 连接断开会触发挂断信号（SIGHUP），前台进程组被整体终止。这与程序本身无关，属于进程管理方式的问题。

方案 A：使用 nohup 后台运行（适合快速验证）

nohup ./startup.sh >/dev/null 2>&1 &

nohup 使进程忽略挂断信号，输出重定向避免占用终端。但它无法解决开机自启和崩溃后自动拉起的问题。

方案 B（推荐）：封装为系统服务，由服务管理器托管

[Unit]
Description=UPS Monitor Service
After=network.target
[Service]
Type=forking
ExecStart=/opt/ups-monitor/bin/startup.sh
ExecStop=/opt/ups-monitor/bin/shutdown.sh
Environment=JAVA_OPTS=-XX:-UseContainerSupport
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target

路径请按实际安装目录调整；若程序只提供前台启动命令，可将 Type 改为 simple 并直接指向前台命令。通过 Environment 注入 JVM 参数，还能把容器感知开关集中在一处管理，避免散落在多个脚本中。

启用服务：

systemctl daemon-reload
systemctl enable --now ups-monitor.service
systemctl status ups-monitor.service

这样程序便具备开机自启、异常自动重启、随系统生命周期统一管理的能力，彻底摆脱对 SSH 会话的依赖。

四、验证清单与长期稳定性建议

修复完成后，建议按以下清单逐项验证：

1. 使用 ps -ef | grep java 确认进程启动参数中包含 -XX:-UseContainerSupport；
2. 查看日志，确认不再出现 ExceptionInInitializerError 及 cgroup 相关堆栈；
3. Web 控制台可正常登录，UPS 的市电状态、电量、负载等信息读取正常；
4. 执行 reboot，确认服务能随系统自动拉起；
5. 条件允许时进行一次真实断电演练，验证告警通知与延迟关机策略是否符合预期。

长期稳定性方面还有几点建议：

• 一台机器上只保留一套 UPS 监控服务，避免设备句柄与端口争抢；
• 为服务配置日志轮转，避免长期运行导致日志膨胀；
• 系统大版本升级后，复查内置组件是否被重新启用（部分系统更新可能重置单元状态），必要时重新执行一遍 mask 操作；
• 同样的排查思路也适用于云环境：在云主机、容器实例等通用计算环境中部署 Java 服务时遇到 cgroup 相关报错（例如在百度智能云等云平台的云服务器或容器服务上），同样可以沿着“确认 cgroup 版本 → 检查 JVM 容器感知 → 调整运行参数”这条链路入手。

五、总结与排查方法论

回顾整个案例，故障表象是“软件坏了”，本质却是“运行环境与程序假设不一致”。可以沉淀出一套通用排查路径：

1. 先读懂异常栈：区分错误发生在 JVM 初始化层、运行环境层还是应用业务层，本例中 CgroupV2Subsystem 直接指明了方向；
2. 再区分“程序 bug”与“环境差异”：同一程序在其他环境正常、唯独特定系统异常时，优先怀疑环境兼容性；
3. 按“消除冲突 → 调整运行时 → 守护化”三步收尾：先停掉争抢资源的内置服务，再为 JVM 关闭不适用的容器感知，最后用服务托管解决“人走服务停”的问题。

其中有两个细节最容易被忽视：一是 disable 与 mask 的语义差异——要彻底屏蔽系统内置服务，必须使用 mask 并覆盖模板单元与聚合单元；二是入口脚本要全部覆盖——只改一处启动参数，往往会留下“时好时坏”的隐患。把这两点做到位，同类故障基本都能一次修复、长期稳定。