DB_postgreSQL

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

최선을 다하자! 2026. 1. 23. 10:16

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을 서비스로 운영한다면
한 번쯤은 반드시 마주치게 될 케이스다.

저작자표시 (새창열림)