재시작은 supervisor가, 상태 설명은 health가 맡아

프로세스는 자기 자신을 재시작하지 않아

macOS의 launchd, Linux의 systemd, supervisord, Kubernetes 중 하나가 충돌 뒤 재시작을 소유하게 해. 서비스 코드가 스스로 재시작을 결정하면 상태와 책임이 꼬여. cwkPippa는 launchd 아래에서 돌고 운영자는 launchctl kickstart -k로 통제된 재시작을 요청해.

살아 있음과 준비됨을 나눠

liveness는 프로세스가 응답할 수 있으면 200을 내고, readiness는 Anthropic 연결과 DB 쓰기, MCP 서버 같은 의존성까지 준비됐을 때만 200을 내야 해. supervisor는 liveness를, 로드 밸런서는 readiness를 보게 해 잘못된 소비자가 장애 판단을 섞지 않도록 해.

자기 코드를 고치는 서비스는 차갑게 재시작해

cwkPippa는 에이전트가 백엔드 코드를 자주 편집하므로 Uvicorn --reload를 쓰지 않아. 자동 재적재는 파일이 반쯤 쓰인 순간을 잡아 충돌할 수 있어. 편집을 끝내고 저장한 뒤 launchd로 한 번 재시작하면 예측 가능하고 StatusBar에도 상태가 보여.

원칙: supervisor가 재시작하고 health가 liveness와 readiness를 구분해. 자기 편집 서비스에는 자동 재적재보다 통제된 차가운 재시작이 맞아.

Code

Liveness vs readiness·python

from fastapi import FastAPI, Response
import httpx

app = FastAPI()

@app.get("/healthz")
async def liveness():
    # 프로세스 up. 그게 의미 전부.
    return {"status": "alive"}

@app.get("/readyz")
async def readiness(response: Response):
    # 트래픽 service 준비? 진짜 의존성 체크.
    checks = {}
    try:
        r = await httpx.AsyncClient(timeout=2).get("https://api.anthropic.com/v1/health")
        checks["anthropic"] = r.status_code == 200
    except Exception as e:
        checks["anthropic"] = False
    checks["db"] = await db_check()
    if not all(checks.values()):
        response.status_code = 503
    return {"checks": checks}

Always-on service 위한 launchd plist (sketch)·yaml

# ~/Library/LaunchAgents/com.example.pippa.plist (실제는 XML)
# Key 필드:
ProgramArguments:
  - /usr/local/bin/uvicorn
  - backend.main:app
  - --host=0.0.0.0
  - --port=8000
KeepAlive:
  SuccessfulExit: false
RunAtLoad: true
StandardOutPath: /var/log/pippa.out.log
StandardErrorPath: /var/log/pippa.err.log
# 재시작 명령: launchctl kickstart -k gui/$(id -u)/com.example.pippa

프로세스는 자기 자신을 재시작하지 않아

살아 있음과 준비됨을 나눠

자기 코드를 고치는 서비스는 차갑게 재시작해

Code

External links

Exercise

Progress

댓글 0