Настройка выполнения агентов Битрикс на Cron — решение проблемы неработающих агентов
Агенты Битрикса – всевозможные фоновые задачи, необходимые для функционирования системы. Согласно официальной терминологии, агенты — технология, позволяющая запускать произвольные PHP функции (агенты) с заданной периодичностью. Технически агент — это запись в специальной таблице:
- какой код надо выполнить,
- когда выполнить,
- с каким периодом выполнять,
- каким способом назначать время следующего запуска агента (строго периодический или нестрого периодический агент).
В самом конце загрузки каждой страницы после отдачи контента браузеру система автоматически проверяет, есть ли агент, который нуждается в запуске и исполняет его в случае необходимости.
Хочу отдельно отметить слова «в конце загрузки страницы». Запомним их.
Что делают Агенты Битрикса и как работают
Агенты осуществляют отправку почты, сбор мусора, обновление системной информации, контролируют состояние сайта, обновляют метрики, проверяют наличие обновлений и т.д. Имеется возможность писать и собственные функции-агенты.
Агенты могут выполняться с разной периодичностью. Раз в несколько минут, раз в час, раз в день или больше.
И вот тут вспоминаем слова «в конце загрузки страницы». Это значит, что, когда кто-то заходит на любую страницу Вашего сайта, Битрикс проверяет, есть ли агенты, которые пора исполнить. Если сайт имеет высокую посещаемость, желательно еще и равномерно распределенную по времени суток, то никаких проблем у Вас не будет.
Однако, если посещаемость сайта не слишком высока (будем реалистами, 10000 хитов в день есть далеко не у всех) – очередь агентов будет расти. И может вызвать проблемы с производительностью у первого посетителя, который попадет на такой сайт. Да, агенты быстро завершат свою работу и сайт начнет работать с достаточной отзывчивостью. Но в самом начале, в первые несколько кликов – сайт может ощутимо тормозить.
Согласно статистики, каждые 100 миллисекунд ожидания снижают конверсию на 7%. Каждые 2 секунды ожидания увеличивают вероятность того, что пользователь покинет сайт на 103%. Хотите ли вы терять потенциального клиента, который ушел из-за таких вот, чисто технических моментов? Конечно, Вы не хотите.
Как правильно настроить Агенты Битрикс
Для этого существует механизм перевода агентов на встроенный в ОС Linux планировщик – cron.
Он заставляет агенты выполняться по расписанию вне зависимости от посещаемости сайта, так как механизм запуска более не привязывается к загрузке страниц. Вместо этого он привязывается к часам на сервере и за своевременный запуск агентов отвечает операционная система.
Вместе с тем, в течение последних лет наблюдается тенденция к замещению функционала планировщика cron другим механизмом – systemd. Подсистема инициализации и управления службами, которая в 2010-2011 годах фактически вытеснила традиционную init, значительно усовершенствовав ее возможности. Новые функции systemd заменили и планировщик cron. Сейчас он есть в большинстве операционных систем семейства Linux, однако оставлен там скорее для обеспечения совместимости, чем для решения реальных задач.
Кроме того, настройка cron имеет свои тонкости, зависящие отконкретного дистрибутива операционной системы, используемой на сервере. Имеет ли смысл досканально изучать устаревший инструмент, каждый решает сам.
Чтобы не терять времени на думы о высоких материях из области эволюции операционных систем, мы рассмотрим вопросы переключения агентов Битрикс на современный планировщик в лице systemd.
Настройка Агентов на cron systemd
Шаг 1. Отключим исполнение агентов по хитам
Для этого перейдем в административную часть сайта, расположенную по адресу example.ru/bitrix/admin.
Далее Настройки – Инструменты – Командная PHP строка.

Впишем туда код:
COption::SetOptionString("main", "agents_use_crontab", "N"); echo COption::GetOptionString("main", "agents_use_crontab", "N"); COption::SetOptionString("main", "check_agents", "N"); echo COption::GetOptionString("main", "check_agents", "Y");
Результат выполнения команды должен отобразить надпись NN
Шаг 2. Внесем изменения в настройки ядра Битрикс
Для этого отредактируем файл /home/bitrix/ext_www/example.com/bitrix/php_interface/dbconn.php
Внимание! Если у вас не подключен мультисайт, то вероятнее всего этот файл находится в каталоге /home/bitrix/www/bitrix/php_interface/dbconn.php
Удалим или закомментируем строки с текстом (если они там есть):
define("BX_CRONTAB_SUPPORT", true); define("BX_CRONTAB", true);
Также в конце файла добавим
if(!(defined("CHK_EVENT") && CHK_EVENT===true)) define("BX_CRONTAB_SUPPORT", true);
В этой же папке создаем (если нет) файл cron_events.php следующего содержания:
$_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__) . "/../.."); $DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"]; define("NO_KEEP_STATISTIC", true); define("NOT_CHECK_PERMISSIONS", true); define('BX_NO_ACCELERATOR_RESET', true); define('CHK_EVENT', true); define('BX_WITH_ON_AFTER_EPILOG', true); require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/modules/main/include/prolog_before.php"); @set_time_limit(0); @ignore_user_abort(true); CAgent::CheckAgents(); define("BX_CRONTAB_SUPPORT", true); define("BX_CRONTAB", true); CEvent::CheckEvents(); if (CModule::IncludeModule('sender')) < \Bitrix\Sender\MailingManager::checkPeriod(false); \Bitrix\Sender\MailingManager::checkSend(); >require($_SERVER['DOCUMENT_ROOT'] . "/bitrix/modules/main/tools/backup.php"); CMain::FinalActions();
Шаг 3. Создадим службу и таймер для ее запуска в systemd
Переместимся в папку /etc/systemd/system и создадим в ней файл bitrix-agents.service
[Unit] Description=Bitrix agents for example.com [Service] User=bitrix Group=bitrix ExecStart=/usr/bin/php -f /home/bitrix/ext_www/example.com/bitrix/php_interface/cron_events.php
Обратите внимание на путь в строке ExecStart. Он должен соответствовать местоположению ранее созданного нами файла cron_events.php.
Создадим второй файл таймера для службы: bitrix-agents.timer. Названия файлов должны совпадать в левой их части, разница только в окончаниях (.service и .timer).
[Unit] Description=Bitrix agents timer for example.com [Timer] OnCalendar=*:0/1 [Install] WantedBy=timers.target
Как мы знаем из шпаргалки, значение OnCalendar=*:0/1 означает выполнение один раз в минуту. Этого более чем достаточно для наших целей.
Шаг 4. Проверим правильность созданной конфигурации
Выполним команды в консоли сервера:
systemctl daemon-reload systemd-analyze verify /etc/systemd/system/bitrix-agents.service systemd-analyze verify /etc/systemd/system/bitrix-agents.timer
Никаких ошибок быть не должно. После этого запустим таймер (и только его!).
systemctl start bitrix-agents.timer systemctl enable bitrix-agents.timer
В результате раз в минуту будет срабатывать созданный нами таймер и связанная с ним служба, которая будет запускать интерпретатор php от имени пользователя bitrix и выполнять в нем файл cron_events.php, который, в свою очередь, запустит выполнение всех нужных агентов.
Убедиться, что все работает можно при помощи команды
systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES Thu 2022-01-20 23:38:00 MSK 52s left Thu 2022-01-20 23:37:01 MSK 6s ago bitrix-agents.timer bitrix-agents.service
Если зайти в административную панель Битрикс и перейти в Настройки – Настройки продукта – Агенты Вы также увидите, что все агенты своевременно выполняются.

На этом на сегодня все.
Запуск агентов 1С Битрикс по крону (cron)
Для запуска агентов 1С Битрикс требуется установка команды планировщика (cron) в панели управления хостингом.
Обратите внимание, что для настройки планировщика для агентов не требуется SSH.

Далее необходимо добавить новый планировщик (cron):
Включите экспертный режим и добавьте следующие значения:

*/5 – минуты
* — часы
* — дни месяцев
* — месяцы
* — дни недели
При этом, тип команды зависит от выбранной версии PHP для сайта (см. раздел «www-домены» в панели хостинга).
Частота запуска CRON должна быть не чаще, чем 1 раз в 3-5 минут во избежании зависания процессов.
Примеры команд запуска агентов (скриптов) по крону для разных версий PHP:
/opt/php53/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php54/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php55/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php56/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php70/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php71/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php72/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php73/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php74/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
/opt/php80/bin/php -f /var/www/ваш_логин/data/www/ваш_сайт/bitrix/modules/main/tools/cron_events.php
Обратите внимание:
Стандартный путь до скрипта запуска агентов может быть изменен на следующий: /var/www/ваш_логин/data/www/ваш_сайт/bitrix/php_interface/cron_events.php
В файле /bitrix/php_interface/dbconn.php требуется убрать любые упоминанаия нижеследующих констант:
BX_CRONTABD BX_CRONTAB_SUPPORT NO_AGENT_CHECK DisableEventsCheck
Добавить строку в этом же файле:
define("BX_CRONTAB_SUPPORT", true); define("BX_CRONTAB", true);
Если после изменений при проверке состояния битрикс-сайта будет отображаться ошибка «Определена константа BX_CRONTAB_SUPPORT в /bitrix/php_interface/dbconn.php, при этом должен быть настроен вызов агентов на cron.» то в этом случае требуется заменить строки:
define("BX_CRONTAB_SUPPORT", true); define("BX_CRONTAB", true);
if(!(defined("CHK_EVENT") && CHK_EVENT===true)) define("BX_CRONTAB_SUPPORT", true);
В некоторых случаях требуется создание файла cron_events.php Убедитесь, что в файловой системе есть файл /bitrix/php_interface/cron_events.php Если он отсутствует, то скачайте и разместите файл в указанной директории.
Обратите внимание:
Установка слишком частого выполнения заданий CRON (планировщика) может вызывать сбои в работе сайта и блокировку выполняющихся процессов. В случае, если на сайте выполняются процессы требующие время на выполнение более 2 минут, то при установке ежеминутного запуска CRON (планировщика) могут появляться очереди запросов к базе данных. Накопление запросов означает, что скрипт незавершает свой процесс и зависает. Рекомендуемый интервал выполнения запуска CRON не чаще 15 минут.
Концепция и все материалы с сайта btrxboost.com включающие в себя текстовую, графическую, видео, аудио и маркетинговую информацию, защищены российским и международным законодательством. В соответствии с соглашением об охране авторских прав и интеллектуальной собственности (ст. №1259, №1260, гл. 70 “Авторское право” ГК РФ от 18.12.2006 № 230-ФЗ) и согласно сертификату собственности авторских прав на информационные материалы RID 07N-4M-48 от 12.08.2012, а также сертификата DMCA id: f25cb914-aba8-4988-a116-13afb399bba2 от 21.06.2019.
В случае нарушений данных правил, применяются следующие меры: подача официального заявления в судебные органы в т.ч. с эскалацией запроса хостинг-провайдеру на котором расположен сайт-нарушитель, а также подача запроса на исключение сайта-нарушителя из поисковых систем согласно “Online Copyright Infringement Liability Limitation Act” по ч. II, раздел 512 к закону об авторском праве по DMCA.
Планировщик задач cron для виртуальной машины 1C-Битрикс (bitrix vm)
Для выполнения «тяжелых» агентов или иных задач (например: пересчет характеристик товаров, выгрузок в xml и т.д.), занимающих длительное время, необходимо использовать планировщик задач cron для linux (в случае виртуальной машины битрикс — это планировщик cron для системы CentOS).
Как сообщает Википедия, планировщик задач cron — это классический демон (компьютерная программа в системах класса UNIX), использующийся для периодического выполнения заданий в определённое время.
Настройка задач выполняется через команду crontab. Напомню, что в виртуальной машине битрикс после установки доступно два пользователя linux: суперпользователь root и пользователь bitrix с ограниченными правами, под которым работает веб-сервер.
Поэтому крайне важно во избежание проблем с правами устанавливать cron-задачи сайтов для пользователя bitrix. Либо воспользоваться советом ниже, используя команду sudo.
Просмотр списка задач пользователя bitrix
Авторизуемся под root к серверу по ssh, выполняем команду:
crontab -l -u bitrix
Список задач текущего авторизованного в систему пользователя (при авторизации под root будут показаны задачи суперпользователя):
crontab -l
Данная команда отображает список уже установленных задач указанного пользователя.
Рекомендую устанавливать для суперпользователя служебные задачи, такие как резервное копирование, обновление сертификатов, перезапуск служб, удаление зависших процессов и т.д.
А задачи, специфичные для сайтов, например, перевод агентов на крон — необходимо ставить под пользователя bitrix.
Редактирование задач пользователя bitrix
Авторизуемся под root к серверу по ssh, выполняем команду:
crontab -u bitrix -e
Данные команда открывает в редакторе специальный текстовый файл в текстовом редакторе vi. Если задачи еще не ставились — он будет пустой.
Важно отметить, что редактор vi работает в двух режимах: в режиме команд и режиме вставки. Чтобы перейти к редактированию текста (режим вставки) необходимо нажать клавишу [i] (insert). Выход из режима редактирования осуществляется клавишей [Esc]. В режиме команд, в статусную строку вводится команда, обычно она начинается с ввода двоеточия. Полезные команды две:
1/ :wq[ENTER] — выйти с сохранением файла
2/ :q! — выход без сохранения файла
Также в режиме команд можно вырезать строку, на которой установлен курсор, через нажатие dd . Для вставки вырезанной строки в указанное курсором место нужно нажать p .

В шапку crontab-файла я рекомендую вставлять комментарий со справкой и сразу покажем пример, как установить выполнение агентов для крон, например, меняем планировщик командой crontab -u bitrix -e со следующим содержимым:
MAILTO="admin1@mail.com,admin2@mail.com"
#
# m h dom mon dow command
#
* * * * * php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php
# если на площадке несколько сайтов и один из них в cp1251,
# а глобально настройки PHP для UTF, то нужно вот так
# переопределить php-ini директивы:
* * * * * php -f -d "mbstring.func_overload"=0 -d "mbstring.internal_encoding"=CP1251 /home/bitrix/ext_www/some_cp1251_site/bitrix/modules/main/tools/cron_events.php
После редактирования рекомендуется перезапустить демон crond:
systemctl restart crond.service
Отладка выполнения cron-скриптов
Для отслеживания вывода cron-задач и получение сообщений об ошибках необходимо указать ящики администраторов в служебной настройке MAILTO вверху файла настроек crontab (можно указать несколько ящиков через запятую).
Чтобы ошибки или результат определенных команд не приходил на ящик, его можно подавить при помощи перенаправления вывода, вот так (выполнять каждые 5 минут с подавлением вывода):
*/5 * * * * php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1
В нашем примере видно, что команда направляет свой стандартный вывод в /dev/null (псевдоустройство, которое может принять произвольный объём данных, не сохраняя их совершенно нигде, следовательно, подавив стандартный вывод). Затем все ошибки (то есть STDERR=2) перенаправить в стандартный вывод. Необходимо поставить амперсанд «&» перед номером назначения (STDOUT=1).
Лог выполнения планировщика crond находится в файле /var/log/cron.
Используем редактор nano вместо vi при редактировании cron-задач
Для того, чтобы использовать более современный текстовый редактор nano, необходимо его установить ( yum -y install nano ), а также указать глобальную переменную окружения:
export VISUAL=nano;

Чтобы вернуться к редактированию crontab через vi нужно поменять значение этой переменной:
export VISUAL=vim;
Организация резервной копии задач
Для организации бекапа задач можно установить задачу для суперпользователя, которая будет сохранять задачи пользователя bitrix в файл.
1/ авторизуемся под root к серверу по ssh
2/ выполняем crontab -e
3/ ставим задачу для пользователя root, ежедневно в 3 ночи сохраняющую задачи пользователя bitrix в файл /home/bitrix/crontab_save.txt
MAILTO="admin1@mail.com,admin2@mail.com"
#
# m h dom mon dow command
#
0 3 * * * crontab -l -u bitrix > /home/bitrix/crontab_save.txt
4/ осталось организовать ежедневное сохранение файла /home/bitrix/crontab_save.txt в свои бекапы настроек сервера. Можно также написать php-скрипт, установленный в крон для root, который будет хранить, например, 3 последние версии данного файла. Это не сложная задача и легко реализуется. Мы у себя сохраняем ежедневно папку /etc и файл /home/bitrix/crontab_save.txt по которому можно в случае ошибки восстановить утерянные cron-задачи.
Когда cron-задачи пользователя bitrix могут сброситься?
В случае если на вашем выделенном сервере с машиной битрикс установлены несколько сайтов со своими отдельными ядрами, каждое ядро содержит свой файл /bitrix/crontab/crontab.cfg
А страница экспорта каждого ядра при этом предлагает установить свои задачи:

Поэтому в файл crontab на вашем сервере надо вносить общий объединенный файл из всех файлов сайтов /bitrix/crontab/crontab.cfg у вас на площадке.
Также крон задачи могут быть переопределены и даже очищены через маркетплейс решение. Например, модуль выгрузки на торговые порталы дописывает в случае необходимости свои задачи в конец crontab файла, не затирая уже установленные задачи. Напоминаю, что apache работает от пользователя bitrix и обладает всеми его привилегиями, т.е. через апатч, а именно функцию exec(‘crontab…’) модуля php апатча можно затереть все задачи пользователя bitrix.
Поэтому в большинстве случаев управлять крон-задачами желательно нужно вручную, это позволит избежать затирания, а также можно при ручном редактировании разбить время запуска тяжелых скриптов разных сайтов, чтобы они не создавали единовременной нагрузки.
Можно ли устанавливать все задачи только для пользователя root?
Это возможно, но не рекомендуется. Для этого можно воспользоваться следующей инструкцией:
1/ авторизуемся под root к серверу по ssh
2/ выполняем crontab -e, т.е. редактируем задачи суперпользователя-root
3/ Используем sudo чтобы php-скрипт выполнялся от пользователя bitrix:
MAILTO="admin1@mail.com,admin2@mail.com"
#
# m h dom mon dow command
#
0 3 * * * crontab -l -u bitrix > /home/bitrix/crontab_save.txt
* * * * * sudo -u bitrix php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1
Cron в Битриксе

Для запуска функций в заданное время, в битриксе существует технология Агентов.
По умолчанию, агенты выполняются на хитах, то есть при каждом посещении сайта пользователем, битрикс проверяет, какие агенты пора запускать и выполняет их. У этого способа есть два недостатка — во-первых, при нерегулярном посещении агенты могут запускаться позже чем нужно. Во-вторых — тяжёлые агенты могут затормозить работу сайта. От обоих недостатков можно избавиться, если запускать агенты с помощью cron.
Чтобы выполнять агенты через крон нужно открыть консоль PHP, находящуюся в Настройки>Инструменты>Командная строка PHP и выполнить команду
COption::SetOptionString(«main», «agents_use_crontab», «N»);
echo COption::GetOptionString(«main», «agents_use_crontab», «N»);
COption::SetOptionString(«main», «check_agents», «N»);
echo COption::GetOptionString(«main», «check_agents», «Y»);
В результате выполнения должно быть написано «NN«.
После этого убираем из файла bitrix/php_interface/dbconn.php определение следующих констант:
define(«BX_CRONTAB_SUPPORT», true);define(«BX_CRONTAB», true);
И заменяем их на:
После этого создаем файл проверки агентов и рассылки системных сообщений. bitrix/php_interface/cron_events.php:
$_SERVER[«DOCUMENT_ROOT»] = realpath(dirname(__FILE__).»/../..»);
$DOCUMENT_ROOT = $_SERVER[«DOCUMENT_ROOT»];
define(«NO_KEEP_STATISTIC», true);
define(«NOT_CHECK_PERMISSIONS»,true);
define(‘CHK_EVENT’, true);
require($_SERVER[«DOCUMENT_ROOT»].»/bitrix/modules/main/include/prolog_before.php»);
@set_time_limit(0);
@ignore_user_abort(true);
CAgent::CheckAgents();
define(«BX_CRONTAB_SUPPORT», true);
define(«BX_CRONTAB», true);
CEvent::CheckEvents();
if (CModule::IncludeModule(«subscribe»))
$cPosting = new CPosting;
$cPosting->AutoSend();
>
?>