Агенты Битрикс на cron молчат после смены PHP при зелёном задании

После смены PHP агенты Битрикс могут стоять при живом CROND: сверьте абсолютный путь к php, LAST_EXEC и вызов cron_events.php.

Сайт открывается, в логах CROND строки идут по расписанию, в админке агенты стоят «на cron» — а письма не уходят, импорт, очистка и синхронизации стоят. После смены PHP на BitrixVM или коробке зелёное задание crontab часто не равно живым агентам: тикает планировщик, молчит LAST_EXEC.

Ниже — как отличить «скрипт дёргается» от «агенты крутятся», что сверить в пути к php и в режиме cron_events.php, и почему после апгрейда ломается именно эта связка.

Как выглядит «cron зелёный — агенты молчат»

Схема: зелёный cron при стоящих агентах и почте

Типичная картина: раньше агенты работали, после апгрейда PHP — нет. CROND логирует CMD каждую минуту, иногда даже mail() из обёртки приходит, а в «Настройки → Настройки продукта → Агенты» время последнего запуска не двигается. Крон отрабатывает; проблема в режиме и скрипте агентов, не в том, «жив ли crond».

Проверка системы показывает текст вроде «последний агент отработал больше суток назад» или ошибку про не настроенный запуск cron_events.php. Если в PHP задана константа BX_CRONTAB_SUPPORT без реальной задачи cron, часть агентов — в том числе почта — останавливается, письма копятся в очереди.

На форуме разработчиков после обновления VMBitrix и PHP до 7.4.x встречался кейс: в логах crond: (php) ERROR (getpwnam() failed) — в строке crontab указан пользователь php. CROND «тикает», агенты мертвы, пока не поправят пользователя и путь к скрипту.

Почему ломается после смены PHP

Сравнение: старый путь PHP против нового интерпретатора

В crontab часто зашит абсолютный путь к старому бинарю. После меню Update PHP появляется новый интерпретатор — в ответах which/whereis встречаются пути вроде /usr/bin/php74 или /usr/bin/php-7.4, — а задание продолжает звать прежний. Скрипт либо не стартует как нужно, либо работает не тем CLI, которым вы пользуетесь вручную.

Второй слой — расхождение режима. Официальный режим «все агенты из cron» требует agents_use_crontab = N и check_agents = N (ожидаемый вывод в PHP-консоли: NN), корректного условия BX_CRONTAB_SUPPORT в dbconn.php и файла cron_events.php. Голые define("BX_CRONTAB_SUPPORT", true) / define("BX_CRONTAB", true) в dbconn без условия с CHK_EVENT — ошибка; ошибочный BX_CRONTAB в dbconn ломает периодические агенты на хитах в смешанном режиме.

Третий слой — неверный файл или дубли: дергается php_interface/cron_events.php и одновременно modules/main/tools/cron_events.php; или в практике встречается путь php_cli/agents.php, который расходится с каноном вендора. Канон урока «Запуск агентов из cron» (COURSE_ID=43, LESSON_ID=2943, изменено 20.11.2025) — cron_events.php.

Как отличить «скрипт дёргается» от «агенты крутятся»

Схема проверки: от лога cron до LAST_EXEC и ручного прогона

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

Таблица b_agent: поля LAST_EXEC и NEXT_EXEC. Если LAST_EXEC не обновляется, выполнение не доходит до записи или падает раньше.
Админка: список агентов; «Настройки → Инструменты → Проверка системы» / site_checker; при необходимости журнал событий.
Типичные ошибки: неверный путь PHP при нескольких версиях; забыли переключить режим агентов; IS_LOCK = Y после сбоя — разблокировать вручную.
Ручной прогон от пользователя сайта: sudo -u bitrix /usr/bin/php -f …/cron_events.php.
CLI timezone должен совпадать с ожидаемым (в отладке на форуме — date_default_timezone_set('Europe/Moscow') в контексте CLI, которым cron вызывает скрипт).

Пока агенты залочены, повторный вызов cron_events.php выходит без повторного запуска — это штатное перекрытие, не «cron сломан».

Что сверить после смены PHP на BitrixVM

crontab -l -u bitrix и/или /etc/crontab плюс /etc/cron.d/bx_* — абсолютный бинарь PHP совпадает с which php / новой версией после Update PHP.
Какой файл дергается: bitrix/php_interface/cron_events.php против bitrix/modules/main/tools/cron_events.php — и не висят ли оба. Если переписали свой php_interface/cron_events.php, штатную запись с modules/main/tools лучше закомментировать.
dbconn.php: условие if(!(defined("CHK_EVENT") && CHK_EVENT===true)) define("BX_CRONTAB_SUPPORT", true); без голого BX_CRONTAB в dbconn.
Пользователь строки crontab — пользователь веб-сервера (bitrix), не php и не root без USERNAME в /etc/crontab. PHP из консоли — с теми же настройками, что веб; иначе кеш и файлы с чужим владельцем.
php -v / php -i CLI против FPM: расширения, memory_limit, timezone.
Через 2–5 минут: LAST_EXEC у системных агентов и проверка системы без ошибки про cron_events.php / «больше суток».

На BitrixEnv задания правят через меню 6. Configure pool sites → 3. Change cron tasks on site: дефолтный сайт — /etc/crontab; сайты из меню — /etc/cron.d/bx_<dbName>. Пример строки BitrixVM из официального урока: */1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php. Чтобы не засыпать почтовый ящик stdout cron — добавить > /dev/null 2>&1.

Официальный каркас режима «все агенты из cron»

Кратко по канону урока LESSON_ID=2943 (не путать с устаревшим LESSON_ID=8897):

В PHP-консоли: agents_use_crontab = N, check_agents = N → вывод NN.
В /bitrix/php_interface/dbconn.php — условие с CHK_EVENT для BX_CRONTAB_SUPPORT, как выше.
Создать /bitrix/php_interface/cron_events.php: DOCUMENT_ROOT через realpath, CHK_EVENT, CAgent::CheckAgents(), затем BX_CRONTAB_SUPPORT + BX_CRONTAB, рассылка Sender, backup.php, CMain::FinalActions().
Альтернатива ядра: /bitrix/modules/main/tools/cron_events.php (пример */10 для частичного режима с agents_use_crontab=Y).

Тяжёлый агент на хите — ориентир больше 10 секунд; на низкой посещаемости это бьёт следующего посетителя. Для почты: mail_event_bulk (пример 20); при проблемах с системными письмами — CACHED_b_event → false.

Не смешивать эту тему с «обновление PHP закрыло CVE»: здесь ломается путь и режим cron после смены версии, а не патч безопасности.

Частые вопросы

Почему после смены PHP агенты молчат, если crontab зелёный?

Частая причина — в задании остался старый абсолютный путь к интерпретатору. CROND запускает строку по расписанию, но агенты не отрабатывают, пока путь не совпадёт с новой версией PHP (which php / whereis php) и корректным cron_events.php.

Достаточно ли смотреть логи CROND, чтобы понять, что агенты живы?

Нет. Лог может показывать CMD каждую минуту и даже успешный mail() из обёртки, а LAST_EXEC в b_agent и время в списке агентов не двигаются. Нужны LAST_EXEC/NEXT_EXEC, проверка системы и отсутствие ошибки про cron_events.php / «агент не отрабатывал больше суток».

Какой файл должен дергать cron — cron_events.php или agents.php?

Официальный канон (урок COURSE_ID=43, LESSON_ID=2943) — cron_events.php в php_interface или modules/main/tools. Путь bitrix/php_cli/agents.php встречается в сторонних заметках и полезен для боли LAST_EXEC и mismatch CLI/web, но не как единственный рецепт вместо канона вендора.

Что проверить в dbconn.php при переводе всех агентов на cron?

Убрать голые define BX_CRONTAB_SUPPORT / BX_CRONTAB; оставить условие с CHK_EVENT для BX_CRONTAB_SUPPORT. Ошибочный BX_CRONTAB в dbconn ломает периодические агенты на хитах в смешанном режиме. Плюс в опциях: agents_use_crontab и check_agents в N (вывод NN).

Как BX Pulse помогает заметить тишину агентов

Аптайм сайта и «зелёный» CROND не равны здоровью фоновых задач Битрикс: почта и агенты могут стоять при живой главной. BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и помогает ловить такие сбои до жалобы клиента. Добавьте первый сайт и настройте уведомления.