안녕하세요 — 공식 Docker 컨테이너의 런타임 사실에 기반하여 이 문제를 엄격하게 다시 정리해 드리겠습니다.
실행 중인 컨테이너에서 확인된 내용 (사실)
이것은 runit이 포함된 공식 Docker 설치 환경입니다 (표준 /var/discourse 런처 워크플로우; 사고 직전에 재빌드가 이루어지지 않음). 컨테이너 내부에서 확인된 사항은 다음과 같습니다:
- runit Sidekiq 서비스가 존재하며, 이 서비스가 감독(supervise)되고 있습니다
ls -l /etc/service/sidekiq/run
sv status sidekiq
사고 당시 출력 결과:
down: sidekiq: 1s, normally up, want up
- 수동으로 Sidekiq를 시작하면 정상 작동합니다
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml
이 방식으로는 프로세스가 유지되며, Redis에 연결되고 작업을 처리합니다.
- /etc/service/sidekiq/run 파일만 패치해도 (재빌드 없이) 크래시 루프가 즉시 해결됩니다.
/etc/service/sidekiq/run을 다음과 같이 대체했습니다:
#!/bin/bash
exec 2>&1
cd /var/www/discourse
mkdir -p tmp/pids
chown discourse:discourse tmp/pids || true
exec chpst -u discourse:discourse \
bash -lc 'cd /var/www/discourse && rm -f tmp/pids/sidekiq*.pid; exec bundle exec sidekiq -C config/sidekiq.yml'
그 후:
sv status sidekiq
run: sidekiq: (pid <PID>) <SECONDS>s
즉, 이 이미지에서 Sidekiq는 Unicorn 마스터를 통해 시작되지 않습니다. 런타임 스크립트가 크래시 루프에 빠질 수 있는 runit 서비스입니다.
정확한 코드를
discourse_docker
레포지토리에서 볼 수 없는 이유
**/etc/service/sidekiq/run은 이미지 빌드/부팅 동안 생성되거나 주입되는 런타임 산출물(runtime artifact)**이기 때문에, discourse_docker에 문자 그대로의 파일로 존재하지 않을 수 있다는 점에는 동의합니다. 그러나 위와 같이, 이 공식 이미지에서 실제로 감독되는 활성 서비스임은 분명합니다.
취약성을 유발한 요인 (사실 + 최소한의 추론)
- 표준 Debian 권한(/var/log = root:adm 0775)으로 인해 logrotate가 매일 실패하는 것도 관찰되었습니다. 전역 su root adm를 추가하기 전까지는 logrotate가 로테이션을 거부했습니다.
- logrotate가 실패할 때 /shared/log/rails/ 하위의 파일들, sidekiq.log를 포함하여 재생성되었습니다.
- 이 이미지의 기본 runit 스크립트는 discourse:www-data를 사용했으며, -L log/sidekiq.log를 /shared/log로 강제했습니다. 이로 인해 Sidekiq는 공유 볼륨 권한 드리프트(perms drift)에 매우 민감해지며, 유용한 로그가 기록되기 전에 즉시 종료될 수 있습니다.
요청 / 제안
위 내용을 고려할 때, 기본 Docker/runit Sidekiq 서비스를 강화하는 방안을 검토해 주실 수 있을까요?
제안하는 기본 설정:
- discourse:discourse로 실행 (컨테이너 내부의 일반적인 소유권과 일치),
- bundle exec sidekiq -C config/sidekiq.yml을 통해 시작,
- 공유 -L log/sidekiq.log를 강제하지 않거나 (또는 이를 견고하게 처리).
이렇게 하면 모든 백그라운드/AI 작업을 중단시키는 조용한 down: 1s 크래시 루프를 방지할 수 있습니다.
지시해 주시는 브랜치/커밋을 테스트해 드릴 수 있습니다.