# Sidekiq runit 脚本过于脆弱：\*\*discourse:www-data\*\* \*\*+ forced\*\* \*\*-L log/sidekiq.log\*\* \*\*导致 1 秒崩溃
**URL:** https://meta.discourse.org/t/sidekiq-runit-script-too-fragile/389331
**Category:** Support
**Tags:** sidekiq
**Created:** [2025年十一月21日 11:56 UTC](https://meta.discourse.org/t/sidekiq-runit-script-too-fragile/389331 "2025-11-21T11:56:44Z")
**Posts on this page:** 1
**Showing post:** 3
### Author:  [@hel\_Sinki](https://meta.discourse.org/u/hel_Sinki)
#### Post date: [2025年十一月23日 14:30 UTC](https://meta.discourse.org/t/sidekiq-runit-script-too-fragile/389331/3 "2025-11-23T14:30:02Z")
您好——我将严格根据官方 Docker 容器的运行时事实重述此事。
### **我在运行的容器中看到的情况（事实）**
这是一个 **官方 Docker 安装，带有 runit** （标准的 /var/discourse 启动器工作流程；事件发生前没有重建）。在容器内：
1. **存在一个 runit Sidekiq 服务，并且是正在被监控的那个**
```plaintext
ls -l /etc/service/sidekiq/run
sv status sidekiq
```
事件期间的输出：
```plaintext
down: sidekiq: 1s, normally up, want up
```
1. **手动启动 Sidekiq 成功**
```plaintext
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml
```
这会保持运行，连接到 Redis，并处理作业。
1. **仅修补** **/etc/service/sidekiq/run** **（不重建）立即修复了崩溃循环** 将 /etc/service/sidekiq/run 替换为：
```plaintext
#!/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'
```
之后：
```plaintext
sv status sidekiq
run: sidekiq: (pid ) s
```
因此，在这个官方镜像中，Sidekiq **不是通过 Unicorn master 启动的** ；它是一个 runit 服务，其运行时脚本可能会陷入崩溃循环。
### **为什么您可能看不到确切的代码在**
### **discourse\_docker 中**
我同意确切的文本可能不在仓库中，因为 **/etc/service/sidekiq/run 是在镜像构建/启动期间生成/注入的运行时工件** ，不一定是 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 **对共享卷权限漂移非常敏感** ，并可能在有有用日志之前立即退出。
### **请求/建议**
鉴于以上情况，我们能否考虑加强默认的 Docker/runit Sidekiq 服务？
建议的默认设置：
- 以 discourse:discourse 身份运行（与容器内的典型所有权匹配），
- 通过 bundle exec sidekiq -C config/sidekiq.yml 启动，
- 避免强制共享的 -L log/sidekiq.log（或使其具有弹性）。
这将防止导致所有后台/AI 作业停止的静默的 down: 1s 崩溃循环。
我很乐意测试您指向我的任何分支/提交。
---
_[View the full topic](https://meta.discourse.org/t/sidekiq-runit-script-too-fragile/389331)._