GVM 登录页报 “service is not responding” 排查与解决方案

GVM 登录页报 "service is not responding" 排查与解决方案

1. 问题现象

The Greenbone Vulnerability Manager service is not responding. This could be due to system maintenance...

账号密码（gvmadmin）本身没有问题，页面能正常打开，但无法登录。

2. 结论（先看这里）

根本原因：gvmd 在同步 SCAP（NVD CVE/CPE）数据时内存暴涨，单进程占用约 14.9GB，耗尽 15GB 物理内存，而 swap 只有约 1GB，最终被系统 OOM Killer 杀掉。

gvmd 是 GSA 的后端，gvmd 不在，页面就提示服务无响应。gsad 和 ospd-openvas 一直是正常运行的。

关键证据：

systemctl status gvm.service：Failed (Result: oom-kill)，日志里有 A process of this unit has been killed by the OOM killer，被杀的进程包括 gvmd 和 xml_split。
dmesg：Out of memory: Killed process 1039 (gvmd) ... anon-rss:14896692kB。
gvmd.log：每次启动都停在 Updating CPEs / Updating .../nvdcve-2.0-20xx.xml，说明 SCAP 同步从未完整跑完。
free -h：物理内存 15GB，swap 仅 975MB。

3. 排查思路（按顺序）

3.1 先确认是哪一层出问题

页面能打开说明 gsad 在运行；报错指向 gsad 连不上 gvmd。所以重点看 gvmd 是否存活。

bash 复制代码

ps aux | grep -E 'ospd|gvmd|gsad|openvas' | grep -v grep
systemctl status gvmd gsad postgresql redis-server@openvas

3.2 识别实际的启动方式（容易走弯路的地方）

systemctl status gvmd 显示 inactive (dead)，但这台机器上 系统自带的 /lib/systemd/system/gvmd.service、gsad.service 并不是实际使用的服务 ，它们里面的路径是空的（如 PIDFile=/gvmd.pid、EnvironmentFile=/gvmd），手动启动必然失败。

实际使用的是自定义的三个单元：

单元	作用
`openvas.service`	启动 ospd-openvas，socket：`/opt/gvm/var/run/ospd.sock`
`gvm.path`	监视 ospd.sock，出现后触发 `gvm.service`
`gvm.service`	启动 gvmd（`--osp-vt-update=/opt/gvm/var/run/ospd.sock`）

另外 gsad 是以 root 在开机时直接启动的（HTTPS 默认端口）。

教训：不要凭服务名猜测，先用 ps aux、systemctl list-unit-files | grep -Ei 'gvm|openvas|ospd|gsad' 和 find / -name 'ospd-openvas*' 确认真实的运行方式，再动手改配置。不要去改自带的 gvmd.service / gsad.service。

3.3 查看 gvm.service 的状态与日志

bash 复制代码

systemctl status gvm.service openvas.service gvm.path --no-pager
tail -n 50 /opt/gvm/var/log/gvm/gvmd.log

看到 Result: oom-kill 后，进入内存方向的验证。

3.4 验证是否 OOM

bash 复制代码

free -h
swapon --show
dmesg -T | grep -iE 'killed process|out of memory' | tail -5

确认 gvmd 的 anon-rss 接近 15GB、swap 只有 1GB，结论成立。

4. 解决方案

4.1 增加 swap（兜底）

先用 df -h / 确认磁盘空间足够，空间不够就把 16G 改成 8G。

bash 复制代码

fallocate -l 16G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
free -h

如果是虚拟机，也可以直接把内存调到更大（官方建议至少 8GB，首次同步建议更多）。

4.2 给 gvm.service 加内存上限

目的：即使 gvmd 再次暴涨，也只限制/杀掉它自己，不拖垮整机。

bash 复制代码

systemctl edit gvm.service

在编辑器里，必须写在 ### Lines below this comment will be discarded 这一行的上方，并且带上 [Service] 节标题：

ini 复制代码

[Service]
MemoryHigh=12G
MemoryMax=14G

保存时 nano 底部会出现临时文件名（形如 .#override.conf...），不要修改，直接回车，再 Ctrl+X 退出。

验证是否生效：

bash 复制代码

systemctl daemon-reload
systemctl cat gvm.service

输出末尾应出现 /etc/systemd/system/gvm.service.d/override.conf 以及上面两行配置。

4.3 重新启动 gvmd

bash 复制代码

systemctl reset-failed gvm.service
systemctl start gvm.service
sleep 5
ps aux | grep gvmd | grep -v grep
tail -n 20 /opt/gvm/var/log/gvm/gvmd.log

看到 gvmd 进程存在后刷新登录页，用 gvmadmin 登录。

4.4 观察同步过程

bash 复制代码

watch -n 5 free -h
tail -f /opt/gvm/var/log/gvm/gvmd.log

gvmd 启动后会在后台继续做 SCAP / VT 更新，可能持续 10～30 分钟，期间不要反复重启。
同步是后台线程，通常 gvmd 进程在跑时登录页就已经可用。
日志中 Updating /opt/gvm/var/lib/gvm/scap-data/nvdcve-2.0-20xx.xml 全部走完，且没有再被 OOM，说明同步成功，之后的增量更新不会再这么吃内存。

5. 如果仍然被 OOM 杀掉

记录卡在哪个 nvdcve 文件，并保存 dmesg 与 free -h 输出。
评估升级 gvmd：21.4.x 较老，对 NVD 2.0 数据处理内存开销大，较新的 22.x/23.x 有改善（源码编译升级前务必先备份 PostgreSQL 数据库）。
临时方案：先保证 VT 扫描可用，SCAP 数据不完整只会影响报告中 CVE 详情的丰富程度，不影响扫描本身。

6. 无关/可忽略的报错

现象	说明
`Unit ospd-openvas.service could not be found`	本环境的服务名是 `openvas.service`，不是故障点
`openvas.service` 里 `ExecStartPre=rm ... status=1/FAILURE`	要删除的 pid/sock 文件本来就不存在，无害
`Unit gsad.service not loaded`	说明该单元已停止，没有 failed 状态可清，可忽略
gsad 日志 `Oops, secure memory pool already initialized`	提示性信息，非故障原因

7. 预防建议

内存建议 8GB 以上（首次同步 SCAP 越大越稳），并配置足够的 swap。
保留 gvm.service 的内存上限配置。
定期查看 /opt/gvm/var/log/gvm/gvmd.log 与 dmesg，发现 OOM 及时处理。
修改配置前先备份，并区分"系统自带模板"和"实际在用的服务文件"。

8. 命令速查

bash 复制代码

# 状态
ps aux | grep -E 'ospd|gvmd|gsad' | grep -v grep
systemctl status gvm.service openvas.service gvm.path --no-pager

# 日志
tail -n 50 /opt/gvm/var/log/gvm/gvmd.log
tail -n 50 /opt/gvm/var/log/gvm/ospd-openvas.log
dmesg -T | grep -iE 'killed process|out of memory'

# 内存
free -h; swapon --show

# 重启 gvmd
systemctl reset-failed gvm.service && systemctl start gvm.service

9. 待确认项

加 swap、设置内存上限并重启后，gvmd 是否稳定运行、SCAP 同步是否完整结束（请把最终结果补充到本文档）。