---
tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
---

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

## 관련 문서
- [24 자동배포 0초 종료와 runtime SSOT 불일치 이슈](../troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md)
- [24서버 robeing runtime workspace-config 단일화](../worklog/260310_24서버_robeing_runtime_workspace_config_단일화.md)
- [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](../troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
- [23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](../troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)

## 목적
- 이번 자동 배포 `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건이 남아 있다.

## 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 복구 진행 중`으로 보는 편이 정확하다.
- 다만 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 deploy SSOT 불일치`가 1차 원인이었음은 확인됐지만, 2026-03-11 기준 남아 있는 최신 `0s` 종료는 `51123 self-hosted runner 실행층 중단`이 더 가까운 원인 후보다.

## 권장
- 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순위: runner 복구가 확인되면 수동 스크립트 의존을 줄이기 위해 systemd 유닛화 또는 동등한 부팅 자동복구 경로를 별도 계획으로 승격한다.