相同Docker镜像中gvmd服务启动异常，寻求排查指导

执行自定义entrypoint.sh脚本后，必须手动执行systemctl start gvmd才能让服务正常运行。且两台配置一致的系统表现不同：一台系统中gvmd可正常启动，另一台因PostgreSQL未完全启动而报错。

entrypoint.sh脚本内容 #

#!/bin/bash
cd /
systemctl start mosquitto.service
systemctl start notus-scanner
systemctl start postgresql@14-main
systemctl start redis-server@openvas.service
systemctl start ospd-openvas
systemctl start gvmd
systemctl start gsad
exec "$@"

日志对比 #

第二台系统（启动失败）的gvmd日志 #

md   main:MESSAGE:2023-01-12 21h05.46 utc:46:    Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
md manage:WARNING:2023-01-12 21h05.46 utc:47: sql_open: PQconnectPoll failed
md manage:WARNING:2023-01-12 21h05.46 utc:47: sql_open: PQerrorMessage (conn): connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  the database system is starting up
md manage:WARNING:2023-01-12 21h05.46 utc:47: init_manage_open_db: sql_open failed

第一台系统（启动正常）的gvmd日志 #

md   main:MESSAGE:2023-01-12 18h06.42 utc:52:    Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
md manage:   INFO:2023-01-12 18h06.46 UTC:72: osp_scanner_feed_version: No feed version available yet. OSPd OpenVAS is still starting
md manage:   INFO:2023-01-12 18h06.56 UTC:80: osp_scanner_feed_version: No feed version available yet. OSPd OpenVAS is still starting
md manage:   INFO:2023-01-12 18h07.06 UTC:84: osp_scanner_feed_version: No feed version available yet. OSPd OpenVAS is still starting

环境信息 #

• 两台系统均为Ubuntu 22.04.1 LTS + Docker 20.10.21
• 使用完全相同的镜像（sha256哈希一致）
• 容器启动命令：docker run --privileged --rm --name openvas -ti <my_image> /bin/bash

排查建议 #

• 给PostgreSQL添加启动等待逻辑：修改entrypoint.sh，启动PostgreSQL后循环检查数据库是否就绪，再启动gvmd。示例代码：

  systemctl start postgresql@14-main
  # 等待PostgreSQL完全就绪
  until pg_isready -U postgres -h localhost; do
      echo "等待PostgreSQL启动完成..."
      sleep 2
  done
  

• 对比服务启动耗时：在entrypoint.sh中添加时间戳日志，记录每个服务启动的时间点（比如echo "$(date): 启动postgresql完成"），对比两台系统中PostgreSQL和gvmd启动的时间差，确认是否是启动速度差异导致。
• 验证PostgreSQL就绪状态：在第二台系统容器内，手动执行systemctl start postgresql@14-main后，立刻运行pg_isready，观察是否需要等待几秒才能返回就绪，确认是否为启动慢的问题。
• 检查主机资源差异：查看两台主机的CPU、内存、磁盘IO使用率，容器运行时可用资源不足可能导致PostgreSQL启动延迟。可使用docker stats openvas查看容器资源占用。
• 查看PostgreSQL启动日志：在第二台系统容器内，检查PostgreSQL的日志文件（通常路径为/var/log/postgresql/postgresql-14-main.log），排查是否有初始化慢、磁盘IO瓶颈等导致启动延迟的原因。

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