[PostgreSQL] Windows 환경에서 PostgreSQL 서비스가 ‘백그라운드로 뜨는 것처럼 보이는’ 이유

Windows 환경에서 PostgreSQL 서비스가 ‘백그라운드로 뜨는 것처럼 보이는’ 이유

– pg_ctl runservice, SCM 타임아웃, 그리고 느린 OS 부팅의 상관관계

1. 문제 현상

onTune V4 (Windows Server 환경)에서 다음과 같은 현상이 발생했다.

• 서버 재부팅 후
• services.msc 에서 onTune_DB 서비스는 정상적으로 올라오지 않았는데
• Task Manager 에는 postgres.exe 프로세스만 다수 실행 중
• 서비스 Stop 버튼은 동작하지 않음
• 결국 수동으로 다음 명령을 실행해야만 DB 종료 가능

 

pg_ctl stop -D "DATA_DIR"

겉으로 보면 마치
“PostgreSQL이 pg_ctl 없이 백그라운드로 혼자 올라온 것처럼”
보이는 상황이다.

---

2. 결론부터 말하면

이 현상은 PostgreSQL이 잘못 기동된 것도 아니고,
pg_ctl을 거치지 않은 기동도 아니다.

실제로는 pg_ctl runservice가 DB를 정상적으로 기동했지만,
Windows 서비스 초기화 타임아웃으로 인해
pg_ctl만 종료되고 postgres 프로세스만 잔존한 상태다.

---

3. onTune_DB 서비스 구조

onTune V4의 DB 서비스는 다음과 같이 등록되어 있다.

 

Path to executable: C:\onTune\database\Postgresql\pgsql\bin\pg_ctl.exe runservice

즉, 구조는 아래와 같다.

 

SCM (Service Control Manager) └─ onTune_DB 서비스 └─ pg_ctl.exe runservice └─ postgres.exe (DB 본체 프로세스들)

여기서 중요한 점은,

• postgres.exe는 DB 엔진 본체
• pg_ctl.exe는 Windows 서비스와 PostgreSQL을 연결하는 wrapper
• Windows는 pg_ctl을 ‘서비스 프로세스’로 인식한다는 점이다.

---

4. Windows 서비스가 요구하는 조건

Windows에서 서비스로 등록된 프로세스는
SCM(Service Control Manager)과 상태 통신을 유지해야 한다.

서비스 시작 시 요구되는 흐름은 다음과 같다.

1. 서비스 시작
2. START_PENDING 상태 보고
3. 초기화가 길어질 경우 상태를 주기적으로 갱신
4. 준비 완료 시 RUNNING 보고

이 과정을 정해진 시간 안에 못 하면
SCM은 해당 서비스를 ‘시작 실패’로 판단한다.

 

 

Postgresql 을 설치하게 되면 의존성이 잡힌다.

---

5. 핵심 원인: ServicesPipeTimeout (30초)

Windows에는 서비스 시작 타임아웃이 존재한다.

• 기본값: 30초
• 레지스트리 위치:

 

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \ServicesPipeTimeout

값이 없으면 기본 30,000ms(30초)가 적용된다.

- 타임아웃 (초) 커스텀 설정 방법

 

 

---

6. 고객사 환경에서 발생한 실제 시나리오

고객사 환경의 특징은 다음과 같았다.

• OS 부팅이 느림
• (추측) 디스크 I/O 지연
• (추측) 보안/백신 

이 상황에서 실제로 벌어진 흐름은 다음과 같을 것 ...

1. OS 부팅
2. RPC / DCOM 관련 핵심 서비스 시작
3. SCM이 onTune_DB 서비스 시작
4. pg_ctl runservice 실행
5. pg_ctl이 postgres.exe 기동
6. PostgreSQL에서 WAL recovery, fsync, 데이터 디렉터리 초기화 수행
7. 이 과정이 30초 초과
8. pg_ctl은 postgres 초기화 대기로 블록됨
9. SCM은 서비스 상태 갱신을 받지 못하고 시작 실패로 판단
10. SCM이 pg_ctl 프로세스 종료
11. 이미 떠 있던 postgres.exe는 그대로 잔존

결과적으로 다음 상태가 된다.

• pg_ctl.exe 없음
• postgres.exe 존재
• 서비스 Stop 불가
• pg_ctl stop 명령으로만 종료 가능 (pg_ctl.exe Stop -D "DATA 경로")

---

7. 왜 ‘백그라운드로 뜬 것처럼’ 보였나?

이 상태를 정확히 표현하면 다음과 같다.

PostgreSQL은 정상적으로 pg_ctl에 의해 기동되었으나,
Windows 서비스 초기화 타임아웃으로 인해
서비스 제어 주체(pg_ctl)가 사라지고
DB 프로세스만 고아 상태로 남은 것이다.

즉, PostgreSQL이 혼자 뜬 것도 아니고
pg_ctl 없이 뜬 것도 아니다.

---

8. 의존성(RPC / DCOM)과의 관계

onTune_DB 서비스의 의존성은 다음과 같다.

• Remote Procedure Call (RPC)
• DCOM Server Process Launcher
• RPC Endpoint Mapper

이 서비스들은 ‘시작됨(Started)’ 상태는 빨리 되지만,
내부 초기화가 끝나기까지는 시간이 걸릴 수 있다.

OS 부팅이 느린 환경에서는
의존 서비스는 Started 상태지만
IPC/DCOM 내부 안정화는 미완료 상태에서
DB 서비스가 기동되며 지연이 누적된다.

---

9. 정리

이 이슈의 본질은 다음 한 문장으로 정리된다.

Windows 환경에서 pg_ctl runservice는
PostgreSQL을 서비스로 실행하기 위한 타협적 구조이며,
느린 OS 부팅 환경에서는 서비스 시작 타임아웃으로 인해
pg_ctl이 종료되고 postgres 프로세스만 잔존하는 현상이 발생할 수 있다.

---

10. 대응 방법

단기 대응으로는

• ServicesPipeTimeout 값을 120초 이상으로 증가
• onTune_DB는 Automatic (Delayed Start) 유지

근본적인 해결로는

• pg_ctl runservice 방식 제거
• Start / Stop을 명확히 제어하는 wrapper 서비스 도입 ? (스크립트를 통해서?)

---

11. 마무리

이 현상은 설정 실수도, PostgreSQL 버그도 아님...

느린 Windows 부팅 환경과 pg_ctl runservice 구조,
그리고 Windows 서비스 타임아웃이 겹치며 발생한 구조적 문제인듯하다.

Windows 환경에서 PostgreSQL을 서비스로 운영한다면
한 번쯤은 반드시 마주치게 될 케이스다.