Скрипт Sidekiq для runit слишком ненадёжен

Поддержка
3

Привет — давайте переформулирую это строго на основе фактов времени выполнения из официального контейнера Docker.

Что я наблюдаю в работающем контейнере (факты)

Это официальная установка Docker с runit (стандартный рабочий процесс запуска /var/discourse; перед инцидентом пересборка не выполнялась). Внутри контейнера:

  1. Существует служба Sidekiq под управлением runit, и именно она находится под наблюдением
ls -l /etc/service/sidekiq/run
sv status sidekiq

Вывод во время инцидента:

down: sidekiq: 1s, normally up, want up
  1. Ручной запуск Sidekiq работает
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml

Процесс остается активным, подключается к Redis и обрабатывает задачи.

  1. Только патч /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. Однако, как показано выше, это именно активная служба под наблюдением в данном официальном образе.

Что вызвало уязвимость (факты + минимальные выводы)

  • Мы также наблюдали ежедневные сбои logrotate из-за стандартных прав доступа Debian: /var/log = root:adm 0775, поэтому logrotate отказывался выполнять ротацию, пока не было добавлено глобальное su root adm.
  • При сбоях logrotate он создавал файлы заново в /shared/log/rails/, включая sidekiq.log.
  • Скрипт runit по умолчанию в этом образе использовал пользователя discourse:www-data и принудительно перенаправлял лог -L log/sidekiq.log в /shared/log, что делает Sidekiq очень чувствительным к дрейфу прав доступа в общих томах и может привести к немедленному завершению работы до появления полезных логов.

Запрос / предложение

Учитывая вышесказанное, можем ли мы рассмотреть возможность усиления защиты службы Sidekiq по умолчанию в Docker/runit?

Предлагаемые настройки по умолчанию:

  • запуск от имени пользователя discourse:discourse (соответствует типичным правам владения внутри контейнера),
  • запуск через bundle exec sidekiq -C config/sidekiq.yml,
  • избегать принудительного использования общего лога -L log/sidekiq.log (или сделать его устойчивым к ошибкам).

Это предотвратит тихий цикл аварийных перезапусков (down: 1s), который останавливает все фоновые задачи и задачи ИИ.

Готов протестировать любую ветку или коммит, на который вы укажете.