Блокируется Cron

[dimassamid]

Здравствуйте!

Столкнулся с такой проблемой. На конференции постоянно блокируется Cron, причём на разных заданиях. Чаще всего это cron.task.core.tidy_sessions и cron.task.core.tidy_cache. Ещё с давних пор у меня стоит расширение Cron Status и за эти годы оно ни разу не выдавало предупреждение о блокировке cron-а, и если бы не оно, то я даже и не узнал бы, что он сломался.

Скриншоты 

Cron Lock 1.png

Cron Lock 2.png

Через час после разблокировки задания выполняются, но Cron снова блокируется

Скриншот 

Cron Lock 3.png

Ещё через час залипнуть может уже другая задача

Скриншот 

Cron Lock 4.png

Иногда, в редких исключениях, все задачи могут быть выполнены и блокировки не возникает. Но это всё на 1-2 часа, до следующуего запуска задачи.

Проблема появилась внезапно около недели назад. Движок не обновлялся, никаких новых расширений не ставилось.

Версия phpBB: 3.3.8
Версия php: 7.4.25

Что я пытался сделать.

• Отключал все расширения.
• Чистил кеш (вручную из папки) и таблицу сессий (из админки).
• Cron был переключён на выполнение через системный планировщик (команда bin/phpbbcli.php cron:run выполнялась раз в 5 минут).

Всё это не дало ровным счётом ничего. В логах apache - ошибок нет, в логах php - ошибок нет. Никакой закономерности выполнения или не выполнения задачи я найти не могу.


С целью проведения экспериментов, я сделал полную копию форума вместе с БД на том же сервере абсолютно с той же конфигурацией (в т.ч. chmod), просто в соседней директории. У сайта другой доменный адрес и всё. И вот уже сутки висит эта копия вместе со всеми включенными расширениями, и Cron ни разу не заблокировался. Какая-то мистика. Может это как-то связано с тем, что на копии нет посетителей (только админ и тестовый аккаунт), а на основном форуме постоянно создаются новые сессии?

Подскажите пожалуйста, куда копать? Как вообще можно поймать ошибку выполнения крона, если ты не программист, а рядовой администратор?
Хочется получить хоть какой-то лог, чего ему не нравится-то

Буду благодарен за любые советы.

[rxu]

Для того, чтобы одномоментно исполнялась только одна задача cron, перед запуском происходит блокировка. То, что она не снимается, говорит о том, что задача по какой-то причине не выполнилась до конца. Через час после блокировки система предполагает, что задача просто зависла, и снимает блокировку. В это время другие задачи cron могут успешно выполняться, пока очередь снова не дойдет до проблемной задачи - тогда цикл повторяется.
То, что ошибки нет в логах, означает, что она не выводится по каким-то причинам (настройки PHP, подавление вывода, еще что-то). С большой долей вероятности при переключении на PHP 8.0 или 8.1 ошибка выявится, так как в этих версиях уровень многих категорий ошибок поднят на 1-2 уровня и подавление вывода для них не работает.

сделал полную копию форума вместе с БД на том же сервере абсолютно с той же конфигурацией (в т.ч. chmod), просто в соседней директории. У сайта другой доменный адрес и всё. И вот уже сутки висит эта копия вместе со всеми включенными расширениями, и Cron ни разу не заблокировался.

Как вариант, какие-то проблемы с таблицами в рабочей БД, может быть, есть резон их проверить/оптимизировать/починить/перепроверить права пользователя БД на различные операции.

[Siava]

Cron был переключён на выполнение через системный планировщик (команда bin/phpbbcli.php cron:run

Если есть консоль и возможность выполнить команду через консоль, то вероятная ошибка там отобразится.
Например

Код: Выделить всё

/usr/bin/php /home/.../forum/bin/phpbbcli.php cron:run

Это лишь пример, надеюсь суть вы поняли.

Только перед запуском команды крона вручную его надо разблокировать.
Для этого в БД таблице phpbb_config надо найти параметр config_name = cron_lock и выставить ему значение config_value = 0

[dimassamid]

Благодарю за советы. Всё проделал, но пока эффекта нет.

• Удалил полностью БД и создал её заново из предварительно сделанного дампа. Подумал, что если с копией форума получилось, то может и тут прокатит, но нет.
• Сделал анализ таблиц в phpmyadmin, везде всё в порядке (статус OK или Table is already up to date)
• Временно перевёл движок на php 8.0. Различных предупреждений повылезало действительно много, но они все связаны со сторонними расширениями, никаких ошибок по крону нет. Вернул назад php 7.4
• В консоли команда выполняется без ошибок. Ошибка выводится уже по факту блокировки крона.
  Скриншот 

  cron lock console.png

Вот ещё один интересный момент.
Самостоятельное выполнение задач от phpBB отключено.
Автоматическое выполнение команды bin/phpbbcli.php cron:run со стороны сервера тоже отключено.
В базе данных снимаю блокировку крону (ставлю cron_lock значение 0). Через минуту Cron снова блокируется.

Скриншот 

cron lock db.png

И так каждый раз. Если никакие задачи не выполняются и Cron по сути выключен, то что может выставлять блок?

[rxu]

Через минуту Cron снова блокируется.

Ну оно понятно, задача не выполняется до конца и до разблокировки дело не доходит. Вопрос только в том, что мешает задаче.

[dimassamid]

Вот ещё такое наблюдение.
Если отключать конференцию, то Cron не блокируется и все задания всегда выполняются как положено. Я пробовал ползать по отключенному форуму, оставлял сообщения, но Cron не ломается.
После включения конференции, Cron снова уходит в блок буквально сразу же. Тоже интересно, с чем это может быть связано.

На данный момент проблема для меня остаётся не решаемой. Буду пробовать дальше ковырять, насколько позволят знания и терпение. Если вдруг получится победить, то обязательно отпишусь.

[Siava]

dimassamid, есть предложение выключить все расширения и поочерёдным включением определить то, которое вызывает проблему.

[dimassamid]

Я уже писал, что расширения отключались все, это не решило проблему.

[dimassamid]

В общем после всех наблюдений, было замечено следующее. Если на форуме ползает много разных гостей-ботов (где-то ~30 разных IP адресов, многие из одной подсети), то cron ломается. Когда на форуме только зарегистрированные пользователи (в т.ч. зарегистрированные боты), то всё в порядке. Это объясняет почему копия форума в соседней директории работала без проблем, там не было ботов.

Мне посоветовали проверить конфигурацию php, apache и т.д., поскольку это похоже на какую-то банальную нехватку серверных ресурсов. Тем не менее, раньше у меня бывало и ~100 одновременных посетителей (включая всевозможных ботов) с той же конфигурацией, и никаких проблем не возникало. Сайт стоит на виртуальном хостинге, но пакет дорогой и нагрузка там не превышает и половину от предоставленной. Обратился к хостеру, но они спрашивают как воспроизвести ошибку. А поскольку никаких ошибок нигде нет, то и предъявить им нечего.
На всякий случай увеличил memory_limit в php.ini с дефолтных 256 МБ до 512 МБ, но это ничего не дало. А что ещё там подкручивать не знаю.

Нашёл для себя два более менее приемлемых варианта, чтобы Cron работал. Пока использую первый, но может перейду на второй.

1. Блокирую "плохих ботов" через Cloudflare и .htaccess. Полёт нормальный, за сутки cron заблокировался лишь 1 раз.
2. Поставил простенькое расширение RegisteredOnly, которое всем гостям показывает только страницу логина и регистрации, без доступа на форум. Когда все "плохие боты" скапливаются на странице логина, то с cron-ом тоже всё в порядке.

Ну вот как-то так

[rxu]

похоже на какую-то банальную нехватку серверных ресурсов

Ну тогда может просто времени на исполнение скрипта не хватает.

[dimassamid]

В конфиге PHP стоит
max_execution_time = 600;

Так или иначе, ошибка должна же уйти в лог, а там ничего нет...

[rxu]

ошибка должна же уйти в лог

С кроном не факт. Но 600 должно быть за глаза.

[dimassamid]

Вот что в логах нашёл ещё:

Скриншот 

bad bots.png

И таких ботов на сайте полно. Все они одновременно сканят и запускают задачи, в том числе и те, которые принадлежат расширениям, например cron.task.core.rxu_tidy_topics, поэтому Cron и валится. Опять же, мне не очень понятно почему это технически происходит. Если время задания не наступило, то URL запрос на выполнение задачи должен, по идее, игнорироваться, разве нет? То есть, как я это понимаю, кроновские страницы можно запрашивать сколько угодно, но это не должно запускать сами задачи (и создавать нагрузку на сервер), если их время не подошло.

Так или иначе, кажется, проблема решена

Как лучше всего заблокировать им доступ? Поскольку Cron запускается через системный планировщик, я думаю будет разумным вообще заблокировать доступ к mysite.ru/cron/* через .htaccess. Что-то типа:

Код: Выделить всё

RewriteEngine On
RewriteRule (^|/)cron(/|$) - [F]

[rxu]

Поскольку Cron запускается через системный планировщик, я думаю будет разумным вообще заблокировать доступ

В таком варианте да.

кроновские страницы можно запрашивать сколько угодно, но это не должно запускать сами задачи (и создавать нагрузку на сервер), если их время не подошло.

В теории так, но, судя по практике, где-то есть проблема при большом количестве таких запросов. Не готов сказать, где именно.
Судя по логу, в течение одной секунды (думаю, что практически одновременно) делается 3-4 запроса к одной и той же задаче, что приводит к ее блокировке (если представить, что проходит несколько запросов до того, как БД успеет записать значение cron_lock в таблицу phpbb_config, то, наверное, такое возможно).

[dimassamid]

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

Заблокировал доступ к /cron через Cloudflare и поставил исключение для своей страны. Вместо страны можно исключить, например, свой IP адрес. Это нужно для того, чтобы в админке нормально работало расширение Cron Status или чтобы иметь возможность самому запускать задачи вручную через браузер.
Вот скриншот конфигурации, вдруг кому пригодится, кто пользуется Cloudflare:

Скриншот 

cloudflare block.png