こんにちは。公式Dockerコンテナの実行時の事実に基づいて、これを厳密に再記述させてください。
実行中のコンテナで見られるもの（事実）
これはrunitを使用する公式Dockerインストールです（標準の/var/discourseランチャーワークフロー。インシデント直前の再ビルドなし）。コンテナ内では：
- runitのSidekiqサービスが存在し、監視されているのがそれです
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がイメージビルド/ブート中に生成/挿入される実行時の成果物であり、必ずしもdiscourse_docker内の逐語的なファイルではないからです。しかし、上記で示したように、これはこの公式イメージ内でアクティブに監視されているサービスです。
脆弱性を引き起こしたもの（事実＋最小限の推論）
- 標準のDebianパーミッションのため、logrotateの失敗も確認されました:/var/log = root:adm 0775であったため、logrotateはグローバルな
su root admを追加するまでローテーションを拒否しました。 - logrotateが失敗したとき、
/shared/log/rails/の下にsidekiq.logを含むファイルを再作成しました。 - このイメージのデフォルトのrunitスクリプトは
discourse:www-dataを使用し、/shared/logに強制的に-L log/sidekiq.logを指定していましたが、これによりSidekiqは共有ボリュームのパーミッションのずれに非常に敏感になり、有用なログが記録される前に即座に終了する可能性があります。
リクエスト／提案
上記を踏まえ、デフォルトのDocker/runit Sidekiqサービスを強化することを検討していただけないでしょうか？
提案されるデフォルト：
discourse:discourseとして実行する（コンテナ内の一般的な所有権と一致）。bundle exec sidekiq -C config/sidekiq.yml経由で起動する。- 共有の
-L log/sidekiq.logを強制するのを避ける（または耐障害性を持たせる）。
これにより、すべてのバックグラウンド/AIジョブを停止させるサイレントなdown: 1sのクラッシュループを防ぐことができます。
ご指定のブランチ/コミットがあれば、喜んでテストします。