手动执行pg_ctl导致Systemd服务状态失效 - 重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛

861296979ba3ca6bdb.png (199.61 KB, 下载次数: 53)

下载附件

2026-1-28 15:26 上传

Step 2: 运维人员切换到 postgres 用户，执行了原生命令 pg_ctl restart。

Step 3: 数据库提示 server started，业务访问完全正常。

216346979ba5347d12.png (123.59 KB, 下载次数: 51)

下载附件

2026-1-28 15:27 上传

Step 4: 返回 root 用户执行 systemctl status postgresql，却发现服务状态是 failed

12286979ba618b147.png (119.18 KB, 下载次数: 52)

下载附件

2026-1-28 15:27 上传

报错核心信息： FATAL: lock file "postmaster.pid" already exists。

133186979ba7bf3813.png (71.14 KB, 下载次数: 53)

下载附件

2026-1-28 15:27 上传

2. 深度解析：消失的“管家”

为什么会报错？这是典型的控制权丢失问题。

Systemd 的逻辑：当你通过 systemctl 启动 PG 时，Systemd 就像一个“管家”，它盯着 PID 为 1111 的主进程。

手动重启的干预：当你执行 pg_ctl restart，你实际上是绕过管家，亲手杀掉了 PID 1111，并开启了一个全新的进程（例如 PID 2520）。

管家的误判：Systemd 发现它盯着的 PID 1111 消失了，立刻触发“故障处理”流程。

结论：数据库内核是健康的，但操作系统层面的服务管理链条断裂了。

3. 生产环境的潜在风险

虽然数据库还在运行，但这种状态有极大隐患：

监控误报：Zabbix、Prometheus 等监控工具通常读取 Systemd 状态，会导致虚假报警。

自启动失效：如果此时操作系统触发重启，Systemd 可能会因为上次是 failed 状态而不去自动拉起数据库。

管理混乱：后续执行 systemctl stop 可能无法正常关闭手动开启的进程。

部分组件功能失效：如无法通过 oracle_fdw 组件访问远程oracle数据库。

4. 最佳实践：统一入口

在安装了 Systemd 的环境下，永远使用 systemctl 替代 pg_ctl：

# 启动
systemctl start postgresql
# 重启
systemctl restart postgresql
# 重载配置（不重启进程）
systemctl reload postgresql

5.救火方案：如何恢复正常状态？

如果你已经不小心手动执行了 pg_ctl restart，请按以下步骤恢复：

手动杀回内核：su - postgres -c "pg_ctl stop"

重新交给管家：systemctl start postgresql