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

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

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

## 문제
- `rb8001` 최신 커밋 푸시 후 Gitea Actions `cicd.yml`이 `0s`로 종료되고 자동 배포가 실제로 수행되지 않았다.
- 같은 시점에 24 실행 서버 `rb8001` 컨테이너는 재시작되지 않았고, 수동 `docker compose down && docker compose up -d --build` 후에만 코드가 반영됐다.
- 2026-03-11 `c7bca94 fix: restore deploy ssot for rb8001` 반영 뒤에도 최신 run `#677`은 여전히 `0s`로 끝나 workflow 본문 실행 증거가 없다.

## 확인된 사실
- 현재 24 실행 서버의 runtime SSOT는 `192.168.0.106`이다.
- 과거 24 주소 `192.168.219.52`는 런타임과 영구 설정 모두에서 제거돼야 하는 대상으로 이미 정리돼 있다.
- 24 실행면의 공용 런타임 값은 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`가 SSOT다.
- 기존 인프라 문서상 배포 실패의 대표 원인은 `DEPLOY_PROJECT_DIR` 같은 단일 기준을 안 쓰고 서비스별 하드코딩 경로/값을 남긴 경우였다.
- 이번 건은 자동 배포가 실행되지 않았지만, 같은 서버에서 수동 배포는 정상 성공했다.
- `rb8001/.gitea/workflows/cicd.yml`은 `secrets.*`나 `vars.*`가 아니라 저장소 루트 `.env.deploy`를 직접 읽도록 작성돼 있다.
- 2026-03-11 `git -C /home/admin/robeing/rb8001 pull` 결과 `0313313..c7bca94`로 갱신됐고, 현재 저장소에는 `.env.deploy` 실파일이 존재한다.
- 현재 `rb8001/.env.deploy`, `.env.deploy.example` 모두 `DEPLOY_SSH_HOST=192.168.0.106`, `DEPLOY_SSH_PORT=51124`, `DEPLOY_PROJECT_DIR=/home/admin/robeing/rb8001`로 정렬돼 있다.
- 반면 `skill_email`, `robeing-monitor`, `skill-rag-file`의 실제 `.env.deploy`는 모두 `DEPLOY_SSH_HOST=192.168.0.106`, `DEPLOY_SSH_PORT=51124`로 맞춰져 있다.
- Gitea API 기준 `rb8001` 저장소의 Actions secrets/variables 목록은 현재 빈 배열(`[]`)이다.
- 2026-03-11 51123 서버에서 `ps -ef | rg 'act_runner|start-act-runner'` 기준 실행 중인 runner 프로세스가 없었다.
- 2026-03-11 51123 서버에서 `systemctl is-active act_runner`는 `inactive`, `systemctl status act_runner`는 `Unit act_runner.service could not be found.`를 반환했다.
- `/home/admin/scripts/start-act-runner.sh`는 systemd 유닛이 아니라 `cd /etc/act_runner && nohup act_runner daemon --config .runner > /mnt/hdd/logs/act_runner/act_runner.log 2>&1 &` 방식으로 runner를 띄우도록 작성돼 있다.
- `/etc/act_runner/.runner`에는 runner id `4`, name `org-shared-runner`, address `http://localhost:3000`, label `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 현재 51123에서 `curl http://localhost:3000/api/healthz`는 `status: 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`, `started=0`, `stopped=0`이라 runner에 task가 할당되기 전 단계에서 멈췄다.
- Gitea DB `action_task` 기준 `rb8001`의 마지막 task 생성 시각은 `2026-03-05 16:23:25+09`이고, 2026-03-06 이후 새 task는 생성되지 않았다.
- 2026-03-11 21:24 KST `sudo /home/admin/scripts/start-act-runner.sh` 실행 후 `act_runner daemon --config .runner` 프로세스가 다시 생성됐다.
- 재기동 직후 `/mnt/hdd/logs/act_runner/act_runner.log`에는 `Starting runner daemon`, `runner: org-shared-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/job은 총 8건이며, `skill-slack`, `skill-email`, `auth-server`, `skill-calendar`, `robeing-monitor`, `admin-dashboard`, `rb8001`, `nginx-infra` 순으로 backlog가 남아 있다.
- 따라서 현재 `rb8001 #677`은 `runner가 죽어서 영구 정지` 상태는 벗어났지만, 아직 자기 차례 task를 받기 전인 queue 대기 상태다.
- 이후 `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 서버 `~/.ssh/authorized_keys`에는 기존 `51123-to-51124-deploy` RSA 키는 있었지만, `github_deploy`에 대응하는 `ssh-ed25519` 공개키는 없었다.
- 2026-03-11 `ssh-keygen -y -f /home/admin/.ssh/github_deploy`로 산출한 `github_deploy` 공개키를 24 서버 `admin ~/.ssh/authorized_keys`에 추가했다.
- 추가 후 51123에서 `ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 'echo SSH_OK'`가 성공해 `23 runner -> 24 SSH 인증` 경로가 실증적으로 복구됐다.

## 현재 해석
- `rb8001` 저장소의 deploy SSOT 불일치 자체는 `c7bca94`로 상당 부분 해소됐고, 이 사실만으로는 최신 `0s` 종료를 더 이상 설명하기 어렵다.
- 현재 우선 원인 후보는 `rb8001 앱`보다 `51123 Gitea Actions self-hosted runner 실행층`이다.
- 특히 runner 프로세스 부재, systemd 유닛 부재, 로그 정지 시점(2026-03-06)이 함께 보여서 최신 `#677`은 workflow 본문 이전 단계에서 종료됐을 가능성이 높다.
- DB 기준으로도 `#677`은 task 미생성 대기 상태라, `0s 종료`는 workflow 내부 스텝 실패보다 `runner fetch/할당 경로 미작동` 해석이 더 맞다.
- 재기동 이후 새 task가 다시 생성되는 것이 실증됐으므로, `runner fetch 경로 자체는 복구 가능`함이 확인됐다.
- 이후 수동 SSH 테스트 결과, 남은 핵심 병목은 `runtime SSOT` 자체보다 `23에서 사용하는 deploy key`가 24에 등록되지 않았던 인증 불일치였음이 확인됐다.
- runner 실행층과 SSH 인증 경로는 각각 별개로 확인됐고, 현재 남은 미해결 범위는 `rb8001` 새 run이 실제로 `Test SSH Connection -> Deploy to Target Server`까지 통과하는지 여부다.
- 다만 `start-act-runner.sh`의 `--config .runner` 사용이 실제 재기동 실패와 연결되는지는 아직 미확정이므로, 관측 사실과 추정 원인을 분리해서 다뤄야 한다.

## 직접 영향
- `git push origin main`이 배포 완료를 의미하지 않게 된다.
- 운영자가 수동 배포로 개입해야 하므로 배포 재현성과 추적성이 깨진다.
- runner가 실제로 죽어 있으면 `rb8001`뿐 아니라 같은 self-hosted runner를 쓰는 다른 저장소도 dispatch를 받아도 실행층에서 멈출 수 있다.

## 한 줄 결론
- 이번 자동 배포 실패는 `rb8001 deploy SSOT 불일치`에서 시작됐지만, 2026-03-11 기준 실증된 직접 병목은 `51123 self-hosted runner 복구 이후에도 남아 있던 23 -> 24 deploy key 인증 불일치`다.