Exec failed ... signal SIGKILL이 보이면, SIGTERM처럼 우아하게 정리된 종료와는 느낌이 다르다. 실제 운영에서는 이 메시지가 프로세스가 스스로 정상 종료한 경우보다 호스트나 런타임이 강제로 끊은 경우에 더 자주 가깝다. 특히 메모리를 많이 먹는 작업, 너무 오래 조용히 도는 작업, background로 넘기지 않고 오래 붙잡은 작업에서 자주 만난다.
공식 Background Exec + Process Tool 문서 기준으로도 오래 걸리는 작업은 yieldMs나 background: true를 전제로 다루고, 상태 확인은 process poll/log로 분리하는 흐름이 기본이다. 즉 SIGKILL이 떴을 때도 출발점은 같다. 명령어 문법부터 다시 쓰는 것보다, 이 작업을 어떤 실행 모드로 돌렸는지 먼저 자르는 편이 훨씬 빠르다.
또 공식 status 문서는 현재 세션과 런타임 상태를 같이 보라고 안내한다. 그래서 SIGKILL을 볼 때는 단순히 한 줄 에러만 보지 말고, 그 직전 작업이 과하게 길었는지, 조용히 멈춰 있었는지, 여러 무거운 작업이 겹쳤는지를 같이 보는 편이 맞다.
AI 생성 결과와 운영 경험을 함께 정리한 문서입니다. 실제 환경에서는 사용 중인 호스트 자원, 세션 상태, 실행 옵션을 함께 확인하세요.
flowchart TD A[Exec failed + signal SIGKILL 확인] --> B{작업 성격은?} B -->|길고 무거움| C[background 또는 yieldMs로 분리] B -->|대화형 CLI| D[pty true 확인] B -->|짧은 작업이어야 함| E[명령/입력 자체 점검] C --> F{로그가 거의 없나?} F -->|예| G[process poll/log로 기존 세션 확인] F -->|아니오| H[직전 출력에서 중단 지점 확인] G --> I{자원 압박 가능성?} H --> I I -->|예| J[작업 단위 축소 또는 동시 실행 감소] I -->|아니오| K[timeout, 실행 방식, PTY 재점검] J --> L[짧게 재시도] K --> L
칠판 치트시트
SIGKILL이면 먼저 강제 종료 상황을 의심한다- 긴 작업은 foreground에 오래 붙잡지 않는다
- 조용한 장기 작업은
process poll/log로 확인한다- 무거운 작업은 한 번에 크게 돌리기보다 나눠서 본다
- 같은 명령을 바로 다시 던지기 전에 기존 세션 종료 원인부터 본다
이런 증상이면 이 문서가 맞다
Exec failed (... signal SIGKILL)이 뜨고 로그가 거의 남지 않는다.- 비슷한 무거운 작업에서만 중간 종료가 반복된다.
- 여러
exec를 겹쳐 돌린 뒤 하나가 갑자기 사라진다. - background 확인 없이 오래 붙잡던 작업이 조용히 죽는다.
SIGKILL일 때 먼저 봐야 하는 것
1) 이 작업을 foreground로 오래 잡고 있지 않았는가
OpenClaw 문서 흐름상 오래 걸릴 수 있는 작업은 처음부터 background나 충분한 yieldMs를 전제로 보는 편이 안전하다. 빌드, 대량 변환, 크롤링, 대규모 검색처럼 길어질 수 있는 작업을 일반 foreground 감각으로 계속 붙잡고 있으면, 중간에 사용 체감과 런타임 관리가 어긋날 수 있다.
실무에서는 아래처럼 나누면 빠르다.
- 10초 안쪽, 출력이 바로 끝남 → foreground 후보
- 수십 초 이상, 중간 출력이 많음 →
yieldMs후 background 전환 후보 - 언제 끝날지 모름 →
background: true우선
2) 자원 압박, 특히 메모리 급증 가능성이 없는가
SIGKILL은 SIGTERM보다 거칠다. 그래서 사용 체감상으로는 “아무 말 없이 끊겼다”에 가깝게 보일 때가 많다. 특히 대형 파일 처리, 무거운 grep/find, 큰 테스트 묶음, 이미지/영상 변환처럼 순간 메모리를 크게 먹는 작업이면 이 가능성을 먼저 보는 게 맞다.
이럴 때는 명령을 더 복잡하게 고치기보다 아래 순서가 낫다.
- 입력 범위를 줄인다.
- 한 번에 처리할 파일 수를 줄인다.
- 같은 시간대에 돌리는 다른 무거운 작업을 줄인다.
- 필요하면 작업을 두세 단계로 쪼갠다.
3) 대화형 CLI인데 PTY 없이 돌린 건 아닌가
대화형 CLI는 PTY가 없을 때 이상한 종료처럼 보일 수 있다. 공식 도구 설명에서도 TTY-required CLI는 pty: true를 쓰라고 안내한다. 즉 인터랙티브 프롬프트, 키 입력, 진행 UI를 기대하는 도구라면 SIGKILL이든 다른 종료든 실행 조건 불일치부터 의심해야 한다.
대표 예시는 아래와 같다.
- Codex, Pi, OpenCode 같은 TTY 성격 도구
- 키 입력을 받는 터미널 앱
- 진행 UI를 강하게 쓰는 CLI
4) 기존 세션 상태를 안 보고 중복 실행하고 있지 않은가
공식 문서대로 long-running work는 process poll/log로 상태를 확인하는 흐름이 기본이다. 여기서 중요한 건, 실패처럼 보이는 순간마다 같은 명령을 다시 던지지 않는 것이다. 이미 비슷한 세션이 살아 있거나 막 죽은 상태에서 재실행을 겹치면 자원 압박이 더 커지고, SIGKILL이 반복되기 쉬워진다.
그래서 복구 순서는 보통 아래가 맞다.
process poll/log로 기존 세션 상태 확인- 조용한 성공인지, 실제 중단인지 분리
- 진짜 중단이면 입력 범위와 실행 방식을 줄여 재시도
가장 빠른 복구 순서
1) 같은 명령 재실행보다 기존 세션 흔적부터 본다
- 방금 background로 넘긴 세션이 있었는지
- 마지막 로그가 어디서 끊겼는지
- 출력이 많다가 끊겼는지, 거의 없었는지
이걸 먼저 보면 문법 문제인지, 자원 문제인지, 실행 모드 문제인지가 빨리 갈린다.
2) 작업 크기를 반으로 줄여서 다시 본다
예를 들어 파일 1000개를 돌렸다면 100개만, 전체 디렉터리 검색이면 하위 한 폴더만, 대형 입력이면 샘플 한 개만 먼저 돌려본다. SIGKILL은 큰 작업에서만 재현되는 경우가 많아서, 작은 샘플이 통과하면 원인을 더 빨리 좁힐 수 있다.
3) 길면 background, 대화형이면 PTY로 다시 맞춘다
- 긴 작업:
yieldMs또는background: true - 대화형 CLI:
pty: true - 끝났는지 애매함:
process poll/log
즉 복구 핵심은 명령을 완전히 다시 짜는 게 아니라 실행 모드 교정이다.
현장 미니 사례 3개
사례 A) 넓은 경로 grep/find 뒤 갑자기 SIGKILL
- 상황: 검색 범위가 너무 넓고 출력도 많았음
- 원인: 작업 범위 과대 + 자원 압박 가능성
- 복구: 검색 루트 축소, 샘플 경로부터 재실행
- 검증: 작은 범위에서는 종료 없이 통과하는지 확인
사례 B) background 확인 없이 무거운 작업을 연속 재실행
- 상황: 끝났는지 몰라 같은 명령을 여러 번 던짐
- 원인: 중복 실행으로 자원 압박 증가
- 복구:
process poll/log확인 후 남은 세션 정리, 단일 재시도 - 검증: 같은 시간대 중복 실행이 사라졌는지 확인
사례 C) 대화형 CLI가 조용히 죽음
- 상황: 입력을 받는 CLI인데 일반 exec처럼 실행
- 원인: PTY 필요 조건 불일치
- 복구:
pty: true로 다시 시작 - 검증: 프롬프트와 진행 UI가 실제로 보이는지 확인
운영자가 바로 판단하는 기준
| 상황 | 먼저 바꿀 것 | 이유 |
|---|---|---|
| 큰 검색, 변환, 테스트 | 작업 범위 축소 | SIGKILL은 과한 작업 크기에서 더 잘 보임 |
| 긴 작업 | yieldMs 또는 background | foreground 장기 점유를 줄임 |
| 대화형 CLI | pty: true | 실행 조건을 맞춰야 함 |
| 조용한 중단 | process poll/log | 무응답과 실패를 구분해야 함 |
| 연속 재시도 중 | 기존 세션 확인 | 중복 실행이 문제를 키울 수 있음 |
검색형 FAQ
Q1. SIGKILL이면 무조건 OpenClaw 버그인가요?
꼭 그렇진 않다. 실제로는 무거운 작업 크기, 잘못된 실행 모드, 중복 실행, 자원 압박 쪽이 더 흔하다.
Q2. SIGTERM과 SIGKILL은 어떻게 다르게 보나요?
운영 체감상 SIGTERM은 정리 가능한 종료에 가깝고, SIGKILL은 더 급하게 끊긴 장면으로 보는 편이 실전적이다. 그래서 SIGKILL에서는 자원 압박과 강제 종료 조건을 먼저 본다.
Q3. 로그가 거의 없으면 뭘 봐야 하나요?
process poll/log로 기존 세션 상태를 먼저 보고, 입력 범위를 줄인 작은 재현으로 다시 확인하는 편이 가장 빠르다.
Q4. 바로 재시도해도 되나요?
권하지 않는다. 기존 세션 상태와 직전 중단 지점을 먼저 확인해야 중복 실행으로 더 악화되는 걸 막을 수 있다.
다음 읽기
- 29. Exec failed (signal SIGTERM)로 중간 종료될 때 해결
- 26. Subagent 돌렸는데 결과가 안 돌아올 때
- 14. OpenClaw 답변 지연, 10분 먹통처럼 보일 때 해결
- 28. OpenClaw 예전 세션이 계속 붙을 때 정리
- 30. OpenClaw 채널은 연결됐는데 답이 없을 때 해결
- 서브에이전트 분산운영
- 34. 세션툴 블로그 검수 자동화
- 🚀 OpenClaw 인덱스
한 줄 결론
Exec failed (signal SIGKILL)은 대개 “명령 한 줄이 틀렸다”보다 작업 크기, 실행 모드, 중복 실행, 자원 압박이 안 맞았다는 신호에 더 가깝다.
같은 명령을 바로 다시 던지기보다, 기존 세션 확인 → 작업 축소 → background/PTY 재정렬 순서로 보면 훨씬 빨리 복구된다.
※ 이 문서는 생성형 AI를 활용해 작성되었습니다.