Make the lock say who the daemon is.

[im-ian]

TL;DR

소켓이 두 질문에 답하고 있었어요 — "데몬이 있나"(소유권)와 "데몬이 응답하나"(준비됨). 앞의 질문은 소켓으로 물을 수 없어요. 소유권을 락으로 옮겼어요.

데몬 2개 동시 기동 × 10회
  BEFORE(main): 두 데몬이 모두 listening = 1 / 10
  AFTER       : 0 / 10

설계

소유권 = 락, 준비됨 = 소켓. 분리하니 ensure_daemon 이 세 상태를 구분해요:

상태	판단	행동
아무도 안 가짐	락 free	새로 띄움
가졌고 응답	락 + 소켓	버전 확인 후 사용
가졌는데 침묵	락 + 소켓 없음	wedged → 놓게 만들고 인수

POSIX record lock(fcntl) — flock 이 못 하는 두 가지 때문이에요: F_GETLK 이 취득 없이 조회하고(취득하는 probe 는 소유자와 구별이 안 돼요), 보유자 pid 를 줘요.

5차 리뷰에서 고친 것 (둘 다 심각, 둘 다 제 코드)

① kill 에 pid 가드가 없었어요. F_GETLK 은 OFD 락에 -1, NFS 원격 보유자에 0 을 줄 수 있어요 → kill(0, SIGTERM) 은 호출자 프로세스 그룹 전체, kill(-1, SIGKILL) 은 사용자의 모든 프로세스. 2차 리비전의 pid as i32 버그를 다른 형태로 다시 만든 거예요.

pub enum Owner { Free, Pid(i32), Unnameable }

이름을 댈 수 없는 소유자에겐 절대 시그널을 안 보내요.

② probe 가 락 파일을 새로 만들었어요. 파일이 지워지면 새 inode 에 F_GETLK → "주인 없음" → cleanup() 이 살아있는 데몬의 소켓을 지워요. 이제 데몬만 생성하고, cleanup 은 락과 소켓을 둘 다 물어봐요.

나머지 반영:

• 버전을 bind 보다 먼저 기록 — 호출자는 소켓이 뜨는 순간 버전을 보는데, 순서가 반대면 그 창이 불일치로 읽혀 정상 기동한 데몬을 죽여요.
• 경쟁에서 진 쪽이 실패 보고 안 함 — 진 쪽 자식은 밀리초에 죽고 이긴 쪽은 아직 로스터를 여는 중이에요. 아무도 안 가질 때까지 계속 기다려요.
• 두 경로가 버전 확인을 공유 — 경쟁에서 진 caller 가 남의 데몬에 새 프로토콜로 말하지 않게.
• graceful 단계에 시작과 같은 예산 — 시그널은 transcript seal 을 건너뛰니, 먼저 물어보고 충분히 기다려요.
• CREW_READY_TIMEOUT 노브 — 로스터 open 시간은 봇·기계·CLI 에 달려서 코드가 볼 수 없어요. 낮게 잡으면 18초째 기동 중인 정상 데몬을 죽여요.
• ESRCH 는 원하던 결과로 처리, 그 외 시그널 실패는 에러로.
• read_pid 삭제(락이 답해요), 중복 dev-dependency 삭제, 테스트의 죽은 산술 제거.
• 테스트에 Drop teardown 가드 — assert 가 터져도 데몬이 락을 들고 남지 않아요.

트레이드오프 (명시)

폴백 없어요. 소유권을 물을 수 없는 홈은 두 데몬을 갈라놓을 수 없는 홈이에요. 조용히 예전 방식으로 내려가 로스터를 깨뜨리는 것보다 에러로 말하는 쪽을 골랐어요.

bind 는 안 옮겨요 — 락이 배제를 하니 live 소켓은 계속 "응답 중". CLI 의 is_socket_live() 게이트 ~15곳 무수정.

검증

• cargo test --locked -p crew — 214 + 3 passed
• 크로스 프로세스 통합 테스트 (record lock 은 프로세스 단위라 in-process 로는 불변식이 깨져도 통과해요):
  • a_second_daemon_is_refused_and_the_first_keeps_serving — 거절 + pid 로 보유자 지목, 첫 번째 도달 가능, stop 후 잔여 없음
  • starting_a_daemon_leaves_one_answering
  • a_wedged_daemon_is_taken_over — SIGSTOP + 소켓 제거 상태에서 인수 (CREW_READY_TIMEOUT 노브도 같이 검증)
• 뮤테이션: 소유권을 소켓으로 되돌리면 FAILED. 자식을 kill 로 회수하면 2개 FAILED
• 경쟁 10회 — 0/10
• stop → 즉시 재기동 6회 (봇 3개) — 0/6
• cargo fmt --check — 변경한 파일 clean

SIGKILL 단계는 테스트로 고정 못 했어요 — SIGSTOP 된 프로세스도 SIGTERM 기본 동작으로 죽어서, 재현엔 uninterruptible 상태가 필요해요. 방어용이고 근거는 커밋에 있어요.

남은 범위 밖

• ensure_daemon 의 최악 대기가 길어요 (wedge 경로에서 기본값 기준 ~40초). desktop::run() 과 sync Tauri command 11곳에서 불려서, Keep the daemon off the main thread. #21 (async command) 과 같이 봐야 해요. 지금도 sync 라 창이 멈춰요 — 이 PR 이 그 시간을 늘려요.
• SIGTERM 기본 동작이 teardown 을 건너뛰는 것(기존 동작). 이제 SIGKILL 이 있어서 brick 위험은 없어요.
• crew.log 무회전

관계

선행 2건 중 두 번째 (첫째 #22 머지됨). #20 은 serve 분리가 여기 들어갔으니 불필요 — 머지 후 닫을게요.

[im-ian]

4차 리뷰 결과 머지 보류. 라운드마다 통합 지점이 새로 깨지는 패턴이 확정적이에요.

가장 문제인 지적: 락이 영구 brick 을 만들 수 있어요. 데몬이 소켓이 죽은 뒤 shutdown_agents 에서 멈추면 (kill 을 무시하는 PTY 자식, 멈춘 디스크의 seal_all_now), 소켓은 영원히 죽어 있고 락은 영원히 잡혀 있어요. ensure_daemon 은 소켓이 live 일 때만 stop_daemon 을 부르니 그 분기를 건너뛰고, spawn 한 자식은 Ok(None) 으로 죽고, 모든 재시도가 같아요. 손으로 crew stop 하기 전엔 앱이 안 떠요.

기존 동작은 10회에 1회 레이스이고 자기 치유돼요. 이 PR 은 그걸 드물지만 복구 불가인 실패로 바꿔요. 나쁜 트레이드예요.

나머지 지적도 전부 맞아요:

• cleanup() 이 여전히 live 소켓을 unlink 함 — ensure_daemon 에서 뺐는데 두 단계 아래에 그대로 있었어요
• daemon_lock_is_free() 가 LOCK_EX 를 실제로 취득해서 probe 함 → probe 하는 쪽이 정상 기동 중인 데몬을 거절시킬 수 있어요
• shutdown_agents() 가 무조건 실행돼서, 폴백 경로에서 seal_all_now() + seal hook 이 이긴 데몬의 transcript 에 써요
• 폴백 경로의 진입부 is_socket_live() → remove_stale_socket() 는 여전히 TOCTOU
• locked 는 "내가 bind 했나" 가 아니라서, 폴백 경로의 이긴 쪽이 자기 뒤처리를 안 함

근본은 이래요: 락을 넣으면 소켓과 수명이 다른 두 번째 소유권 신호가 생기고, 기존 흐름 전부(ensure_daemon, stop_daemon, wait_dead, cleanup, teardown, main.rs 의 ~15개 is_socket_live() 게이트)를 다시 유도해야 해요. 패치가 아니라 재설계예요.

[im-ian]

6차 리뷰 결과 머지 보류 권고. 두 가지가 결정적이에요.

① 이 설계의 전제가 성립하지 않아요. is_socket_live() 는 connect 가능 여부만 봐요. bind+listen 한 프로세스가 멈춰도 커널 backlog(128)가 연결을 받아줘서, connect 는 계속 성공해요. 리뷰어가 실측으로 확인했어요 — SIGSTOP 된 리스너에 connect 5회 전부 성공.

즉 "락은 잡혀 있는데 응답 없음 = wedged" 라는 판별이, 가장 흔한 wedge 형태(데드락·SIGSTOP·shutdown_agents 에서 멈춤 — 소켓은 여전히 bound)에서 "정상"으로 읽혀요. 제 통합 테스트가 wedge 를 만들려고 remove_file(crew.sock) 를 손으로 해야 했던 게 그 신호였는데 제가 못 알아봤어요. 제대로 하려면 readiness probe 가 실제 Ping RPC 여야 하고, 그러면 ANSWER_TIMEOUT(15초)·최악 대기 예산과 다시 얽혀요.

② 6라운드 중 4번, 제 코드에 심각한 결함이 있었어요.

라운드	결함
2차	pid as i32 음수 → kill(-1, 0) 이 영구 성공
4차→5차	child.kill() 이 방금 띄운 데몬을 죽임
5차	kill 에 pid 가드 없음 → kill(0)=프로세스 그룹, kill(-1)=사용자 전체
6차	return ensure_daemon() 무한 재귀 — 인플레이스 업데이트 시 매 라운드 정상 데몬을 SIGKILL

전부 리뷰나 실측이 잡았고 제가 스스로 잡은 건 없어요.

이번 라운드 나머지 지적도 맞아요: run() 에서 소켓 가드를 지워서 락 파일이 재생성되면 두 데몬이 뜸 / Owner::Free 분기가 응답 중인 데몬을 두고 Ok 반환 / cleanup() 의 check-then-delete 레이스 / pid 를 35초 전에 샘플링해 재활용 pid 에 시그널 / bind 전 crew stop 이 유예 없이 SIGTERM / SIGKILL 이 에이전트 자식을 남김 / probe 가 write 권한을 요구해 권한 없으면 영구 brick / 최악 대기 4초 → 65초.

권고: 닫고, 이 레이스는 알려진 한계로 기록. 발생 대가는 10회에 1회이고 자기 치유돼요. 여섯 번 시도해서 매번 그보다 나쁜 걸 넣었어요.

살릴 가치가 있는 건 serve() 분리 하나예요 — 부팅 실패 시 로스터 orphan 방지. 소유권 의미와 무관해서 3라운드 동안 지적이 없었어요. 따로 작은 PR 로 낼 수 있어요.

[im-ian]

닫습니다. 6라운드 리뷰 후 전제를 다시 측정했고, 제가 틀렸어요.

계측 트레이스:

d1: is_socket_live=false, exists=false → unlink(no-op) → 20 agents → 로스터 전체 open
    → about to bind; exists=true  → EADDRINUSE → 사망
d2: 동일 경로 → about to bind; exists=false → 서비스

측정된 피해가 이 PR 을 정당화했던 시나리오와 달라요:

• 실사용 봇은 전부 headless (uses_pty_program 이 grok/claude/codex 만). headless 봇 6개 부팅 → registered 6줄, CLI 프로세스 0개. 패자가 띄우는 게 없어요.
• PTY 봇의 자식은 패자와 함께 죽어요 (PTY master 닫힘 → SIGHUP). 봇 6개 경쟁 후 남은 프로세스 6개(승자 몫), 12개 아님.
• "둘 다 bind" 는 빈 로스터에서만 재현돼요 (1/12). 봇 3개 0/12, 봇 20개 0/1. 그때 도달 불가 데몬은 아무것도 안 들고 있어요.

즉 "두 데몬이 모든 에이전트를 같은 transcript 에 spawn"·"orphan 된 CLI 자식" 은 측정에서 재현되지 않아요. 저는 리뷰의 시나리오 서술을 검증 없이 전제로 받아 여섯 번 고쳤고, 그중 네 번은 그보다 나쁜 결함을 넣었어요 (kill(-1), 방금 띄운 데몬 자살, kill(0), 무한 재귀).

레이스는 알려진 한계로 기록하고, 측정으로 남은 유일한 실제 문제 — 패자가 ? 로 죽어 shutdown_agents() 를 안 거치는 것 — 만 별도 PR 로 냅니다.