Тест сердцебиения Sidekiq не удался, перезапуск

Поддержка Самостоятельное хостинг
1

Привет! Я обнаружил странную ошибку на своей админ-странице: Sidekiq не запущен.
Я открыл логи и нашел сотни ошибок, похожих на следующие:

/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:112:in `report_to_store'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:103:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:54:in `add'
/usr/local/lib/ruby/2.6.0/logger.rb:534:in `warn'
config/unicorn.conf.rb:147:in `check_sidekiq_heartbeat'
config/unicorn.conf.rb:164:in `master_sleep'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:296:in `join'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

А вот ошибки из приложения:

run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/letsencrypt
[Wed 01 Jan 2020 10:40:41 AM UTC] Domains not changed.
[Wed 01 Jan 2020 10:40:41 AM UTC] Skip, Next renewal time is: Tue Feb 25 00:52:11 UTC 2020
[Wed 01 Jan 2020 10:40:41 AM UTC] Add '--force' to force to renew.
[Wed 01 Jan 2020 10:40:41 AM UTC] Installing key to:/shared/ssl/discourse.example.com.key
[Wed 01 Jan 2020 10:40:41 AM UTC] Installing full chain to:/shared/ssl/discourse.example.com.cer
[Wed 01 Jan 2020 10:40:41 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Wed 01 Jan 2020 10:40:41 AM UTC] Reload error for :
[Wed 01 Jan 2020 10:40:42 AM UTC] Domains not changed.
[Wed 01 Jan 2020 10:40:42 AM UTC] Skip, Next renewal time is: Wed Jan  8 00:39:10 UTC 2020
[Wed 01 Jan 2020 10:40:42 AM UTC] Add '--force' to force to renew.
[Wed 01 Jan 2020 10:40:42 AM UTC] Installing key to:/shared/ssl/discourse.example.com_ecc.key
[Wed 01 Jan 2020 10:40:42 AM UTC] Installing full chain to:/shared/ssl/discourse.example.com_ecc.cer
[Wed 01 Jan 2020 10:40:42 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Wed 01 Jan 2020 10:40:42 AM UTC] Reload error for :
Started runsvdir, PID is 628
chgrp: invalid group: ‘syslog’
rsyslogd: imklog: cannot open kernel log (/proc/kmsg): Operation not permitted.
rsyslogd: activation of module imklog failed [v8.1901.0 try https://www.rsyslog.com/e/2145 ]
supervisor pid: 633 unicorn pid: 647

Я пытался очистить базу данных Redis, но это не помогло.
У меня отдельные контейнеры для приложения, PostgreSQL и Redis.
Есть какие-то идеи, как это исправить?

2

Sidekiq приостановлен? Не накапливается ли очередь задач?

3

В очереди по умолчанию отображается 2 задания, оба типа Jobs::VersionCheck.
После очистки базы данных Redis отображается: 0 выполненных заданий, 0 неудачных, 2 в очереди.

На странице планировщика видно, что некоторые задания находятся в очереди или выполняются, но эти задания не учитываются в статистике на странице Sidekiq. У всех заданий на странице планировщика длительность либо пустая, либо равна -1 мс.

Таким образом, цифры не меняются, буквально ничего не происходит.
Как проверить, приостановлен ли Sidekiq?

4

Та же проблема с последним обновлением, никаких изменений, кроме обновления через пересборку. В админ-панели указано, что Sidekiq не запущен. У меня PostgreSQL и Redis работают в контейнерах, а приложение — в другом; я перезапустил их все. Очереди содержат несколько сотен задач, но ничего не обрабатывается.

РЕДАКТ1: Очистка всех очередей не помогла и ничего не исправила; они снова заполняются, но задачи всё равно не обрабатываются.

РЕДАКТ2: Я пересобрал форум со всеми вытекающими простоями, но сообщение осталось:

image
image1084×160 14.4 KB

Очереди в /sidekiq не обрабатываются. До обновления с beta7 до 2.4.0.beta9 всё работало без проблем.

РЕДАКТ3: Свободного места более 50 ГБ. Ручное выполнение резервного копирования (чуть менее 300 МБ) прошло успешно; система сообщает о паузе и возобновлении работы Sidekiq, ошибок в логах нет, но Sidekiq, похоже, всё ещё не запущен?

РЕДАКТ4: Единственный примечательный лог в /logs — повторяющееся сообщение Sidekiq heartbeat test failed, restarting.

РЕДАКТ5: Redis, похоже, работает нормально, по крайней мере, его лог-файл активно сообщает, что ему почти нечего делать… И для ясности:

[3] pry(main)> Sidekiq.paused?
=> false

РЕДАКТ6: Я очистил очереди некоторое время назад, сейчас снова 10 задач в очереди, но они не обрабатываются.

РЕДАКТ7: Нашёл, что bundle exec sidekiq — обычный способ запуска Sidekiq в стандартном проекте, поэтому давайте попробуем запустить его и посмотреть, что произойдёт:

root@vps198273-forum:/var/www/discourse# bundle exec sidekiq
2020-01-06T05:10:18.814Z pid=31242 tid=gn383wxbu INFO: Booting Sidekiq 6.0.4 with redis options {:host=>"forum-data", :port=>6379, :namespace=>"sidekiq", :id=>"Sidekiq-server-PID-31242", :url=>nil}
Вы подключаетесь к Redis v3.0.6, Sidekiq требует Redis v4.0.0 или новее
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/lib/sidekiq/cli.rb:62:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/bin/sidekiq:12:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/sidekiq:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/sidekiq:23:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'

Вы подключаетесь к Redis v3.0.6, Sidekiq требует Redis v4.0.0 или новее

Ну, это выглядит интересно? Давайте попробуем пересобрать контейнер данных и помолимся, чтобы не трогать данные, lol…

РЕДАКТ8: Похоже, сейчас запущен Redis 5.0.5 (почему для этого не используется pubsub от PostgreSQL?), что определённо 4.0.0 или новее… Пересборка завершена, тестируем форум, данные вроде бы на месте, и у нас всплеск!

image
image367×572 61.8 KB

Кажется, исправлено! Возможно, этот пост кому-то пригодится. Жаль, что форум не показал ошибку Sidekiq о устаревшей версии Redis, но, наверное, эти логи просто улетают в неведомую бездну, так как я нигде их не нашёл. ^.^

5

Это очень хорошая работа по расследованию, надеюсь, это поможет другим.

6

Как вы получили древний Redis? Вы используете нестандартную установку?

7

Я использую настройку с несколькими контейнерами и никогда не пересобирал Redis.
Попробую пересобрать Redis.

ОБН.
@OvermindDL1, спасибо за решения. Я пересобрал контейнер Redis, и теперь всё работает.

Sidekiq — это библиотека фоновых задач, и она зависит от Redis. Она супероптимизирована и зрела, но поддерживает только бэкенд Redis.
Я также думаю, что message_bus (реалтайм-функции Discourse) использует Redis «под капотом».

8

Стандартная установка через Docker с разделёнными контейнерами согласно инструкции (чтобы я мог собрать новую версию Discourse и быстро переключиться на неё без простоя), но я не трогаю контейнер с данными, где, как выяснилось, работает Redis (я думал, что он будет в основном контейнере, поэтому удивился, когда не смог найти его запущенным в основном контейнере).

Да, у меня точно так же, как у @arrowcircle. :slight_smile:

9

В конфигурации с двумя контейнерами всё равно необходимо пересоздавать контейнер с данными; рекомендую планировать эту операцию как минимум раз в год.

10

Есть ли способ сделать это без простоя? В этом и была суть их первоначального разделения.

11

Для обеспечения работы без простоев вам потребуется запустить реплику Redis и реплику базы данных. Тем не менее, при переключении на резервную систему (failover) всё равно будет наблюдаться кратковременная фаза только для чтения.

Да, всё это технически реализуемо, но для этого вам потребуется нанять команду инфраструктурных специалистов.

12

Всё с открытым исходным кодом, без денег. ^.^;