Docker中PostgreSQL 13.11进程被Hangup终止的原因排查

环境与故障信息 #

• 数据库环境：PostgreSQL 13.11（Debian 13.11-1.pgdg110+1）运行于Docker容器，配置：shared_buffers = 1GB，work_mem = 4MB，maintenance_work_mem = 128MB
• 应用报错：org.postgresql.util.PSQLException: 向后端发送数据时发生I/O错误
• 数据库日志：单个后端进程（PID 339174）被信号1（SIGHUP）终止，Postmaster随后终止所有活跃进程，触发自动恢复；恢复期间应用连接报FATAL: 数据库系统处于恢复模式，最终恢复完成
• 补充信息：故障数据库仅30MB，同服务器其他数据库服务正常，无OOM-killer触发迹象

排查步骤 #

• 检查Docker容器操作记录：

  • 查看容器自身日志（docker logs <容器ID/名称>），确认故障时间点是否有容器重启、配置重载或其他操作
  • 查看宿主机Docker事件日志（docker events --since "<故障时间前10分钟>" --until "<故障时间后5分钟>"），排查是否有外部触发的容器相关事件（如stop/restart、信号发送）

• 验证容器内信号来源：

  • 进入容器，检查Debian系统日志（cat /var/log/syslog | grep "<故障时间>"），查找是否有进程信号发送的相关记录
  • 排查容器内是否存在第三方进程/脚本，误将SIGHUP信号发送到目标PostgreSQL后端进程

• 排查PostgreSQL进程行为异常：

  • 检查故障数据库在故障发生前的慢查询、长事务记录（查看pg_stat_activity历史快照，或启用了log_statement/log_min_duration_statement的话看对应日志），确认是否有特殊操作导致进程被标记需要终止
  • 确认是否有针对该数据库的维护操作（如VACUUM FULL、ALTER TABLE），这类操作是否可能触发异常信号传递

• 检查Docker资源限制与cgroup状态：

  • 查看容器的资源配置（docker inspect <容器ID/名称> | grep -A10 "Resources"），确认是否存在CPU、内存的软限制，是否因资源阈值触发信号
  • 检查宿主机对应容器的cgroup日志（如/sys/fs/cgroup/memory/docker/<容器ID>/memory.stat等），排查是否有资源异常导致的进程信号

• 宿主机层面信号审计：

  • 若宿主机启用了auditd服务，查看审计日志（ausearch -m signal -ts "<故障时间>"），排查是否有外部进程向容器内的PostgreSQL PID发送SIGHUP信号
  • 检查宿主机上的定时任务、监控脚本，确认故障时间点是否有自动执行的操作会发送信号到容器进程

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