24 자동배포 0초 종료와 runtime SSOT 불일치 리서치

목적

이번 자동 배포 0s 종료를 애플리케이션 문제가 아니라 인프라 배포 경로 SSOT 불일치 -> 51123 runner 실행층 순서로 좁혀 닫기 위한 확인 포인트를 정리한다.

확인된 SSOT

24 실행 서버 기준 주소: 192.168.0.106
과거 24 주소: 192.168.219.52 사용 금지
24 실행면 공통 런타임 값 기준: /home/admin/workspace-config/runtime.env, /home/admin/workspace-config/secrets.env
배포 경로 기준: 서비스별 하드코딩이 아니라 workflow 변수/secret의 단일 기준 사용

Facts

2026-03-11 git -C /home/admin/robeing/rb8001 pull 결과 0313313..c7bca94로 fast-forward 됐다.
현재 rb8001/.env.deploy, .env.deploy.example는 모두 192.168.0.106:51124, DEPLOY_PROJECT_DIR=/home/admin/robeing/rb8001 기준으로 정렬돼 있다.
rb8001/.gitea/workflows/cicd.yml은 여전히 저장소 루트 .env.deploy를 직접 읽는 구조다.
최신 run #677은 여전히 0s 종료로 보이며, workflow 본문 단계 로그가 확인되지 않았다.
2026-03-11 51123에서 ps -ef | rg 'act_runner|start-act-runner' 기준 실행 중인 runner 프로세스가 없다.
같은 시각 systemctl is-active act_runner는 inactive, systemctl status act_runner는 Unit act_runner.service could not be found.를 반환했다.
/etc/act_runner/.runner에는 org-shared-runner, http://localhost:3000, self-hosted:host가 등록돼 있다.
/mnt/hdd/logs/act_runner/act_runner.log의 마지막 성공 실행은 2026-03-05 robeing-monitor 배포였고, 마지막 오류는 2026-03-06 failed to fetch task ... dial tcp 127.0.0.1:5432: connect: connection refused다.
2026-03-11 현재 curl http://localhost:3000/api/healthz는 pass이고, ss -tlnp 기준 3000, 5432는 모두 listen 상태다.
Gitea DB action_runner 기준 runner id 4의 last_online은 2026-03-06 08:11:27+09, last_active는 2026-03-05 16:38:37+09다.
Gitea DB action_run 기준 rb8001 최신 run #677은 status=5, started=0, stopped=0 상태다.
Gitea DB action_run_job 기준 #677의 deploy job은 task_id=0이다.
Gitea DB action_task 기준 rb8001의 마지막 task 생성은 2026-03-05 16:23:25+09다.
2026-03-11 21:24 KST sudo /home/admin/scripts/start-act-runner.sh 실행 후 act_runner daemon --config .runner 프로세스가 다시 생성됐다.
재기동 직후 act_runner.log에는 Starting runner daemon, runner ... declare successfully, 신규 task 2109, 2110 시작 로그가 남았다.
Gitea DB action_runner 기준 runner id 4의 last_online, last_active는 2026-03-11 21:25:15+09로 갱신됐다.
2026-03-11 21:25 KST 기준 pending run은 총 8건이며, rb8001 #677 앞에 더 이른 시각의 pending run 6건이 남아 있다.
이후 rb8001 workflow 화면상 Setup SSH는 통과했고 Test SSH Connection 단계에서 약 57초 정체했다.
현재 rb8001/.env.deploy의 DEPLOY_SSH_KEY_PATH는 /home/admin/.ssh/github_deploy다.
2026-03-11 51123에서 ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 수동 접속은 Permission denied (publickey,password)로 실패했다.
24 서버 admin ~/.ssh/authorized_keys에는 기존 51123-to-51124-deploy RSA 키는 있었지만, github_deploy의 ssh-ed25519 공개키는 없었다.
ssh-keygen -y -f /home/admin/.ssh/github_deploy로 산출한 공개키를 24 authorized_keys에 추가한 뒤, ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 'echo SSH_OK'가 성공했다.

Interpretation

수동 배포가 정상 성공하고, .env.deploy 계열도 c7bca94 이후 SSOT에 맞춰졌기 때문에 rb8001 코드나 현재 저장소 파일 상태만으로 최신 0s 종료를 설명하기는 어렵다.
따라서 원인 후보 우선순위는 배포 파일 부재에서 51123 self-hosted runner 실행층 중단으로 이동한다.
특히 runner 프로세스가 현재 없고 로그도 2026-03-06 이후 멈춰 있으므로, 최신 #677은 workflow 본문 실행 전 dispatch/task fetch 단계에서 종료됐을 가능성이 높다.
action_run_job.task_id=0와 action_task 신규 생성 부재가 함께 보여서, 최신 이슈는 job 생성 후 task 할당이 되지 않는 상태로 보는 것이 가장 근거가 강하다.
다만 재기동 뒤 신규 task가 실제로 다시 생성되는 것이 확인됐으므로, 지금 남은 상태를 runner fetch 경로 완전 불능으로 보기는 어렵고 backlog 복구 진행 중으로 보는 편이 정확하다.
이후 단계별 수동 검증으로 보면, Setup SSH 통과와 github_deploy 직접 인증 실패가 함께 확인돼 남은 병목은 23 runner가 읽는 deploy key와 24 authorized_keys의 불일치로 좁혀진다.
공개키 추가 후 SSH_OK가 즉시 반환됐으므로, 현재는 23 -> 24 SSH 인증 경로 자체는 복구된 상태로 판단할 수 있다.
다만 2026-03-06의 127.0.0.1:5432 connection refused가 단발성인지, runner 중단의 직접 원인인지, 현재 재시작 불가와 연결되는지는 아직 확정할 수 없다.

Unresolved

Gitea UI에서 runner가 현재 online/offline 중 어떤 상태로 표시되는지
start-act-runner.sh가 systemd 없이 수동 실행만 전제하는 구조가 의도된 운영 기준인지
start-act-runner.sh의 act_runner daemon --config .runner가 실제 재기동 실패와 연결되는지
최신 #677 dispatch/task가 Gitea DB에는 남았지만 runner가 fetch하지 못한 상태인지
runner 재기동 직후 action_runner.last_online이 현재 시각으로 갱신되는지
runner 재기동 후 #677이 기존 pending 상태에서 순차 처리되는지, 아니면 새 run을 만들어야 하는지
runner 재기동 후 동일 커밋 재실행 시 workflow 본문 로그가 실제로 생기는지
rb8001 새 run이 Test SSH Connection 이후 Deploy to Target Server까지 실제로 통과하는지
24 서버에서 최종 배포 성공과 후속 정리(worklog, 닫힘 기준)가 확보되는지

결론

현재는 rb8001 deploy SSOT 불일치가 1차 원인이었고, 2026-03-11 기준 남은 직접 병목은 51123 runner 복구 이후 드러난 23 -> 24 deploy key 인증 불일치로 보는 것이 가장 근거가 강하다.

권장

1순위: /home/admin/scripts/start-act-runner.sh로 runner를 재기동하고 ps -ef, act_runner.log, action_runner.last_online 갱신 여부를 동시에 확인한다.
2순위: backlog가 실제로 줄어드는지 확인하고, rb8001 #677이 대기열을 지나도 task_id=0이면 그때 #677 재실행 또는 새 push로 재트리거한다.
3순위: github_deploy 공개키가 24 authorized_keys에 유지되는지 확인한 뒤 rb8001만 재실행해 Test SSH Connection과 실제 배포 단계를 통과하는지 검증한다.
4순위: runner 복구가 확인되면 수동 스크립트 의존을 줄이기 위해 systemd 유닛화 또는 동등한 부팅 자동복구 경로를 별도 계획으로 승격한다.

8.0 KiB Raw Blame History

24 자동배포 0초 종료와 runtime SSOT 불일치 리서치

관련 문서

목적

확인된 SSOT

Facts

Interpretation

Unresolved

결론

권장

8.0 KiB

Raw Blame History