Завис cron на Битрикс: что делать по шагам

Сайт открывается с HTTP 200, а письма, обмен с 1С и индексы молчат уже сутки. В Проверке системы красное "Не настроен запуск cron_events.php… последний агент отработал больше суток назад" – cron или агенты зависли. За 20–30 минут вы отличите "планировщик не крутится" от "залип один агент", почините PHP CLI / crontab / BX_CRONTAB и получите движущиеся LAST_EXEC/NEXT_EXEC без сюрпризов от клиентов.

Зависший cron на 1С-Битрикс: Управление сайтом – это не "сайт упал", а мёртвые фоновые задачи при живой витрине. Сначала снимите симптомы в Проверке системы и списке агентов, затем сверьте crontab и путь PHP CLI, потом константы BX_CRONTAB. После починки закрепите контроль просрочки NEXT_EXEC, иначе инцидент вернётся незаметно.

Речь только про CMS "1С-Битрикс: Управление сайтом" на своём хостинге. Это не Bitrix24 CRM и не облачный портал – инструкции для них сюда не подходят.

Типичная ловушка: после смены PHP в панели в crontab остался старый /usr/bin/php. Cron "тикает", письмо из скрипта иногда приходит, а периодические агенты стоят. Через сутки админка орёт про сутки без агентов. Ниже – triage от симптомов к разблокировке и контролю.

Разберите симптомы: сайт жив, бизнес-процессы нет

Сначала зафиксируйте, что именно сломалось. Агент в Битрикс – это PHP-задача по расписанию (почта, обмен, индексация). Cron – планировщик операционной системы, который должен раз в 1–5 минут вызывать скрипт cron_events.php. Путаница этих двух слоёв даёт ложные "починки".

Сделайте: запишите время, текст ошибки Проверки системы и 2–3 агента с отстающим NEXT_EXEC. Не делайте: считать HTTP 200 доказательством, что "всё работает" – витрина и фоновые задачи живут раздельно. Разовая проверка доступности описана в как проверить работоспособность сайта.

Откройте Проверку системы и список агентов

Официальные точки в админке CMS:

1. Откройте /bitrix/admin/site_checker.php (Настройки → Инструменты → Проверка системы) и найдите блок про агенты/cron.
2. Откройте /bitrix/admin/agent_list.php (Настройки → … → Агенты) и отсортируйте по NEXT_EXEC / LAST_EXEC.
3. Сравните LAST_EXEC с "сейчас": если сутки и больше – это ваш инцидент; сразу запишите NAME функций агентов, которые должны ходить часто (почта, обмен, поиск).
4. Отметьте, есть ли агент с RUNNING=Y дольше обычного интервала.

Схема triage:
Проверка системы → список агентов (LAST/NEXT) → crontab пользователя сайта → ручной php -f …/cron_events.php → dbconn (BX_CRONTAB) → RUNNING/DATE_CHECK → контроль просрочки

Сделайте: идите сверху вниз и не прыгайте сразу в SQL. Не делайте: удалять агенты из списка "на всякий случай" – сначала поймите функцию по NAME. На практике так меньше ложных "починок".

Проверьте crontab и путь PHP CLI пошагово

По документации crontab должен быть у того же OS-пользователя, что и сайт (часто bitrix). Иначе скрипт не достучится до кеша и файлов.

1. Посмотрите задания: crontab -l или crontab -u bitrix -l, либо раздел Cron в панели хостинга.
2. Убедитесь, что есть вызов cron_events.php – из bitrix/modules/main/tools/ или копии в php_interface/ – с интервалом 1–5 минут (часто */1).
3. Сверьте бинарь PHP: which php / путь из панели должен совпадать с версией сайта, не со старым /usr/bin/php.
4. Запустите вручную: time php -f /path/to/bitrix/modules/main/tools/cron_events.php от пользователя сайта.
5. Прочитайте вывод: Parse error в ядре почти всегда значит "CLI старше/младше, чем FPM сайта".
6. Если предыдущий запуск ещё висит, новый по доке не стартует агентов – сначала найдите долгий процесс, не плодите параллельные вызовы.

После смены PHP это частая поломка: планировщик "живой", а CLI падает на синтаксисе. Чините путь в crontab, не переустанавливайте CMS.

Сделайте: один успешный ручной прогон CLI до правок в БД. Не делайте: держать тяжёлые задачи (>10 сек по курсу) только на хитах – их место на cron.

Исправьте BX_CRONTAB и режим "агенты на cron"

Если cron тикает, а периодические агенты молчат, почти всегда виноваты константы и опции режима.

• В dbconn.php не должно быть ошибочного define("BX_CRONTAB", true). Эта константа живёт внутри cron-скрипта; в dbconn она убивает периодические агенты (официальный текст Проверки системы).
• Для режима "все агенты на cron" обычно нужна поддержка BX_CRONTAB_SUPPORT и отключение выполнения на хитах (check_agents=N через настройки/консоль по курсу).
• Проверьте timezone CLI: расхождение часов даёт странные NEXT_EXEC при "успешном" mail-тесте.
• Опции check_agents / DATE_CHECK в b_option могут блокировать запуск – сбрасывайте только если понимаете эффект.

Сделайте: уберите BX_CRONTAB из dbconn, оставьте поддержку cron и ежеминутный вызов скрипта. Не делайте: копировать куски из гайдов облачного портала – у CMS другие файлы и другой смысл "агентов".

Разблокируйте зависший агент без ломания очереди

Когда инфраструктура cron в порядке, а очередь стоит, ищите залипший агент.

1. В списке агентов или SQL по b_agent найдите строки с RUNNING=Y и давно не обновлявшимся LAST_EXEC.
2. Прочитайте NAME: бэкап, импорт, обмен – кандидат на "тяжёлую" задачу, которая блокирует общий cron_events.php.
3. Осторожно сбросьте RUNNING / DATE_CHECK по проверенной процедуре (админка или точечный SQL) – не удаляйте агент вслепую.
4. Вынесите тяжёлую работу на отдельное задание cron со своим lock, чтобы не душить почту и индексы.
5. Через 5–15 минут снова откройте agent_list: LAST_EXEC должен сдвинуться, Проверка системы – перестать ругаться на сутки.

Kill PHP на сервере – крайняя мера админа ОС, не кнопка из админки.

Сделайте: разблокируйте после чтения NAME. Не делайте: чистить b_agent "под чистую" – снесёте штатные задания модулей.

Закрепите результат: мониторинг просрочки NEXT_EXEC

Разовая починка без контроля вернёт тот же звонок через неделю. Нужен сигнал "агенты отстали", а не только "порт 443 отвечает".

• Минимум: SQL/heartbeat по агентам, у которых NEXT_EXEC старше порога (например 30–60 минут для частых задач).
• Модуль вроде Agent Watch на Marketplace – Email/Telegram по просрочке, если не хотите писать свой watcher.
• Внутренние проверки BX Pulse включают срез по агентам (cron) – удобно рядом с uptime, без подмены одного другим.

Общую схему внешних алертов и Инспектора не дублируем здесь: как собрать мониторинг сайта на Битрикс – в гайде по мониторингу. Как узнать о падении витрины раньше клиента – в статье как узнать, что сайт упал. Здесь важнее другое: после зелёного HTTP всё равно проверяйте движение агентов.

Чтобы держать метрики CMS и uptime рядом, подключите сайт в BX Pulse или посмотрите demo – ранний сигнал по агентам рядом с доступностью.

Сделайте: добавьте алерт по просрочке NEXT_EXEC в проде. Не делайте: "раз в неделю глазами в agent_list" как единственный контроль.

Что сделать дальше за 15 минут

1. Прогоните Проверку системы и сохраните скрин блока агентов/cron.
2. Сверьте crontab и PHP CLI ручным php -f …/cron_events.php.
3. Уберите ошибочный BX_CRONTAB из dbconn, если он там есть.
4. Разблокируйте залипший RUNNING только после чтения NAME.
5. Поставьте контроль просрочки NEXT_EXEC.
6. Добавьте ссылку на runbook мониторинга в дежурную папку.

Результат, который вы получите: site_checker не орёт про сутки, критичные LAST_EXEC двигаются, а следующий сбой ловится алертом, а не клиентом в мессенджере.

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, разработчик 1С-Битрикс.
Источники: курс: запуск агентов из cron, выполнение агентов на Cron, список агентов, bitrix-tools/env-docker.