설정 파일을 고쳤다고 서비스가 바뀐 건 아니다 — plist·실행 환경·시작 시각을 함께 본다

설정 파일을 고쳤다고 서비스가 바뀐 건 아니다 — plist·실행 환경·시작 시각을 함께 본다

macOS 백그라운드 브릿지의 기능을 켜기 위해 LaunchAgent plist 값을 0에서 1로 바꾸고 서비스를 재시작했다. 그때는 정상 작동했지만, 뒤이은 설치 작업이 예전 plist를 다시 복사하면서 기능이 조용히 꺼졌다. 파일만 보면 설정 문제이고, 프로세스만 보면 재시작도 이미 된 상태라 원인을 놓치기 쉬웠다.

핵심은 원하는 설정, 디스크에 남은 설정, 실행 중 프로세스가 실제로 받은 설정이 서로 다른 상태일 수 있다는 점이다.

세 층을 따로 확인한다

1. 설정 파일: plist에 기대값이 저장되어 있는지 읽는다.
2. 실행 환경: 현재 PID의 환경에서 같은 값이 실제로 적용됐는지 읽는다.
3. 시작 시각과 PID: 설정 파일 수정 뒤 새 프로세스가 떴는지 확인한다.

plutil -p ~/Library/LaunchAgents/com.example.worker.plist
pid="$(pgrep -f 'worker.py' | head -1)"
ps eww -p "$pid" | tr ' ' '\n' | grep '^FEATURE_FLAG='
ps -p "$pid" -o lstart=,etime=,command=

plist가 1인데 프로세스가 0이면 재시작이 빠진 것이다. 둘 다 0이고 파일 수정 시각이 최근이면 다른 설치·동기화가 설정을 되돌린 것이다. 둘 다 1인데 기능이 없다면 그때부터 애플리케이션 로직과 입력 조건을 본다.

룰

• 설정 변경 완료는 파일 diff가 아니라 새 PID의 실행 환경으로 판정한다.
• 재설치·동기화 스크립트가 plist를 배포한다면 그 원본도 같은 값으로 맞춘다.
• launchctl bootout → 해제 확인 → bootstrap 순서를 쓰고, 이전 PID가 사라졌는지 확인한다.
• 기능 테스트가 실패해도 무조건 재시작부터 반복하지 않는다. 먼저 세 층 중 어디가 어긋났는지 이름을 붙인다.

한 문장으로. 설정의 진실은 편집한 파일 한 장이 아니라 디스크 값·실행 환경·프로세스 세대가 일치할 때 확정된다.