ES /docs

Cupix::Event logger init fails — permission denied on log file

Summary: Cupix::Event logger init fails — Permission denied on tesla_production-event.log

Outcome#

자동 코드 fix 미수행 (fix_failed → 운영 핸드오프).

사용자가 선택한 "즉시 조치 (Critical)" 항목은 RCA 가 명시적으로 운영 인프라 작업 (EB 호스트의 chown/chmod) 으로 정의한 범위이며, "코드 변경은 즉시 단계에서 불필요"라고 명시했습니다. 따라서 본 cluster 에서는 commit 가능한 코드 변경이 없습니다.

추가로, 가장 가까운 과거 episode (TSLA-12569 / a9c32b99) 가 도입한 postdeploy touch + chown 패치는 현재 master 의 .platform/hooks/postdeploy/70|71|72_restart_sidekiq.sh 에 이미 모두 적용되어 있어 추가로 변경할 코드 영역이 없음을 확인했습니다.

Hand-off to Operations#

운영팀이 다음 단계를 EB 운영 환경에서 수동 수행해야 합니다:

1. 영향 호스트 식별#

Datadog 에서 본 cluster 와 묶인 호스트들의 host / eb_instance_id 추출:

text
service:cupixworks-worker status:error "Permission denied @ rb_sysopen" "tesla_production-event.log"

2. 호스트 inspect#

각 영향 인스턴스에서:

sh
# SSM Session Manager 또는 EB SSH
sudo ls -l /var/app/current/log/ | grep tesla_production-event
sudo stat /var/app/current/log/tesla_production-event.log

소유자가 webapp:webapp (또는 EB 의 AppUser) 가 아니라 root 등으로 되어 있다면 권한 불일치가 root cause 입니다.

3. 권한 복구#

sh
sudo chown -R webapp:webapp /var/app/current/log/
sudo chmod 664 /var/app/current/log/tesla_production-event.log*

로테이트된 daily 파일들 (tesla_production-event.log.YYYYMMDD) 도 동일하게 처리.

4. 검증#

복구 후 Sidekiq worker / cron runner 가 다시 정상적으로 event log 를 append 할 수 있는지 확인:

sh
sudo -u webapp touch /var/app/current/log/tesla_production-event.log
echo $?  # 0 이어야 함

이후 14일 baseline 대비 후속 발생이 사라지는지 Datadog 으로 모니터링:

text
service:cupixworks-worker status:error "Permission denied" "tesla_production-event.log"

Why fix_failed (not pr_created)#

본 cluster 는 코드 변경이 아닌 운영 절차 로 해결됩니다. resolution: fix_failed 는 "code-fix skill 이 자동화 코드 변경을 만들 수 없었다"는 의미이며, 실제 운영 영향이 해결 불가능하다는 뜻은 아닙니다. 운영팀의 호스트 권한 복구로 즉시 해결 가능합니다.

Worktree Cleanup#

(생성된 worktree 없음 — 정리할 항목 없음)

Recurrence Watch / Follow-up#

운영팀의 호스트 권한 복구 후에도 동일 에러가 14일 내 재발하면, 다음 코드 변경을 별도 cluster fix 로 진행하는 것을 권장합니다 (RCA 의 "단기 개선" 옵션 B):

  • app/models/concerns/eventable/events/base.rb:18 — Cupix::Event.publish 의 실패가 state machine transition 자체를 raise 시키지 않도록 별도 rescue 로 분리. 이로써 logger 권한 이슈가 발생해도 비즈니스 transaction (job stopped 처리) 은 정상 종료됨.

장기 개선으로는 RCA 에 명시된 "이벤트 publish 채널 일원화 (파일 → STDOUT → CloudWatch / Datadog)" 가 가장 근본 해결책입니다.

Artifacts#

  • state.mdx — phase 전이 기록 (모든 implement/validate/pr phase = skipped)
  • plan.mdx — 즉시 조치 범위 분석 및 코드 변경 부재 근거
  • validation.mdx — verdict: skipped
  • rca.mdx — 원본 RCA 보고서 (수정 없음)