Выполнение агентов на cron bitrix ошибка

Не важно, где находится файл, главное какой из них будет запускаться через cron. И какой код внутри файла. Я недавно переводил себе агентов на крон (у меня из 87). Мой файл www/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(‘BX_NO_ACCELERATOR_RESET’, 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’, true);  
CAgent::CheckAgents();  
require($_SERVER[‘DOCUMENT_ROOT’].’/bitrix/modules/main/tools/backup.php’);
CMain::FinalActions();

В    /bitrix/php_interface/dbconn.php    убрал  define(«BX_CRONTAB_SUPPORT», true);   и    define(«BX_CRONTAB», true);
В cron была одна запись, выполняющая cron_events.php каждые 2 мин.
Всё работало, только процесс крона зависал на сервере и приходилось применять KILL к процессам. Тогда я для каждого агента написал свой php файл (который запускает агента) и отдельную запись в 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С-Битрикс: Управление сайтом» — одна из самых популярных коммерческих CMS. Как и в случае с любой другой CMS, при работе с Битриксом возникают разные ошибки, мешающие нормальной работе сайта. Выявить их можно с помощью встроенного функционала проверки системы в панели администратора Битрикс.

Чтобы запустить проверку системы, перейдите в панель администратора по ссылке https://example.com/bitrix/admin (замените example.com на ваш домен), введите логин и пароль учетной записи администратора сайта, перейдите в Настройки — Инструменты — Проверка системы и нажмите на кнопку Начать тестирование. Дождитесь окончания проверки. В форме Проверка системы могут быть ошибки, которые, на первый взгляд, не влияют на работу сайта, однако требуют внимания владельца или системного администратора сайта.

В данной статье рассмотрим способы устранения популярных ошибок, возникающих в CMS Битрикс.  

Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт

Такая ошибка в большинстве случаев означает некорректное подключение к базе данных. В первую очередь проверьте, работает ли СУБД, введя следующую команду в терминал:

# systemctl status mysql

Если СУБД работает, проверьте файлы, расположенные в /home/bitrix/www/bitrix/.settings.php и /home/bitrix/www/bitrix/php_interface/dbconn.php (при необходимости замените /home/bitrix/www на корневую директорию вашего проекта, далее в статье будут использованы относительные пути вида /bitrix/php_interface/dbconn.php). В этих файлах указываются доступы для подключения к базе данных сайта.

Для файла .settings.php

'host' => 'localhost',
'database' => 'database_name',
'login' => 'user_name',
'password' => 'secret_password',

Для файла dbconn.php

$DBHost = "localhost";
$DBLogin = 'user_name';
$DBPassword = 'secret_password’;
$DBName = "database_name";

Проверьте корректность указанных данных:

• хост базы данных (должен быть localhost, если СУБД установлена локально),
• название базы данных (замените в обоих файлах database_name на название своей базы данных),
• имя пользователя базы данных (замените user_name на имя своего пользователя базы данных)
• и пароль пользователя базы данных (замените secret_password на пароль пользователя вашей базы данных).

Иногда бывает, что при развертывании сайта из бэкапа на новом сервере вместо данных указываются звездочки. В таком случае просто укажите свои данные в обоих файлах.

«Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы 

При проверке системы Битрикс часто возникает замечание выполнения агентов на cron. Данное замечание не мешает работе сайта, однако может повлиять на выполнение разных функций вашего проекта, например, на отправку почты.

Как правило, для настройки выполнения агентов на cron достаточно следовать рекомендациям проверки системы. Для этого нажмите на вопросительный знак справа от уведомления:

Однако такой способ срабатывает не всегда. Если в файле /bitrix/php_interface/dbconn.php есть строка define('BX_CRONTAB_SUPPORT', true); и в cron есть задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.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");

Результат выполнения PHP-команды должен быть «NN».

Далее в файле /bitrix/php_interface/dbconn.php закомментируем следующие строки (добавьте перед строками знак #):

define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);

После чего в этот же файл dbconn.php добавьте строки:

if(!(defined("CHK_EVENT") && CHK_EVENT===true))
define("BX_CRONTAB_SUPPORT", true);

Далее необходимо из учетной записи владельца сайта (если вы работаете в консоли сервера из-под учетной записи root, что не рекомендуется, после создания файла измените владельца файла с помощью команды chown) создать новый файл cron_events.php в директории /bitrix/php_interface/ и добавить в него следующий код:

<?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();
?>

После того, как файл создан с нужными правами, добавляем его в cron. Обязательно делаем это для владельца сайта, так как задания cron для пользователя root могут стать серьезной угрозой безопасности для сайта и сервера. Выполним следующую команду (в нашем случае владелец сайта — bitrix, замените это значение на имя пользователя своего сайта при необходимости):

# crontab -ubitrix -e

Откроется файл с заданиями crontab пользователя сайта. Вставьте следующую строку:

*/1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php

В данной строке значение */1 * * * * означает выполнение скрипта раз в минуту, вы можете скорректировать частоту выполнения в зависимости от ваших требований к проекту.

Путь /usr/bin/php — путь для PHP, оставьте его таким же, если у вас на сервере нет альтернативных версий PHP. Если вы используете панель ISPmanager, возможно, ваш сайт работает на альтернативной версии PHP. Проверить версию можно в панели ISPmanager, а узнать корректный путь для PHP — с помощью команды whereis php в консоли сервера. Например, для альтернативной версии PHP 8.1 путь может быть таким: /opt/php81/bin/php. Замените путь к скрипту /home/bitrix/www/bitrix/php_interface/cron_events.php на свой в случае необходимости.

Если в cron есть запись для выполнения скрипта /var/www/bitrix/modules/main/tools/cron_events.php — ее лучше закомментировать.

Ошибка работы с сокетами при проверке системы

При проверке системы в панели администратора Битрикс может возникнуть ошибка «Работа с сокетами. Ошибка! Не работает».

Также из-за ошибки работы с сокетами другие тесты проводятся некорректно, выдавая ошибку «Замечание. Не удалось проверить из-за ошибки в работе с сокетами».

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

Если А-записи указаны корректно, возможно в файле /etc/hosts на сервере указан неверный IP для вашего домена. Проверьте файл и укажите правильное значение:

1.2.3.4 example.com

Замените 1.2.3.4 на IP адрес вашего сервера, а example.com на доменное имя вашего сайта.

Бывает, что на сервере может возникнуть проблема с корневыми сертификатами. Можно попробовать обновить их. В CentOS 7 ведите в консоли сервера:

# yum install ca-certificates -y
# update-ca-trust

Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы

Из описания ошибки понятно, что она означает. В большинстве случаев для устранения данной ошибки требуется вмешательство системного администратора или технической поддержки Битрикс. Проблем, из-за которых почта не работает, много. Они могут быть на стороне сервера, в настройках проекта, либо из-за некорректно работающих модулей отправки почты.

Битрикс использует стандартную функцию php mail() для отправки почты, однако нередко используются другие способы, например, через внешний почтовый сервер. Для проверки работы php mail() можно воспользоваться инструкцией из ответов на часто задаваемые вопросы на форуме Битрикс. 

Также можно выполнить проверку с помощью следующего кода PHP (вставьте его в командную строку PHP в панели администратора Битрикс):

$mail="test@testmail.ru"; // укажите ваш почтовый ящик, на который нужно отправить тестовое письмо
$subject ="test" ; // укажите любую тему письма
$text= "test message"; // укажите любой текст письма
if( mail($mail, $subject, $text) )
{
echo 'Письмо отправлено!'; }
else{
echo 'Ошибка! Не отправлено';
}

Если письмо не пришло, но вы получили уведомление «Письмо отправлено», значит, письма уходят и проблема в настройках CMS либо в модуле отправки почты. В данном случае можно обратиться в техподдержку Битрикс для выявления проблем в настройках CMS или к разработчику модуля отправки почты.

Не исключено, что письмо просто попало в спам. Можно попробовать отправить на другой почтовый ящик (с другим почтовым доменом). Если письмо пришло — значит, адрес отправителя в черном списке почтового домена, до которого письмо не дошло. Если письмо не дошло — возможно, ваш почтовый домен или IP-адрес попали в глобальные черные списки.

Если письмо не пришло, а вы получили уведомление «Отправка не удалась» — необходимо более детальное изучение проблемы. В таком случае потребуется вмешательство системного администратора.

«Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы

Такая ошибка говорит о наличии в корне сайта служебных скриптов, например, restore.php. Данные скрипты, как правило, добавляют временно для проведения каких-либо работ (например, restore.php — для восстановления сайта из резервной копии). Так или иначе, после выполнения работ такие скрипты необходимо удалить с сервера, так как они представляют угрозу безопасности сайту и данным.

Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы

Проверка системы Битрикс загружает файл размером более 4Мб. В большинстве случаев такая ошибка говорит об ограничениях в параметре upload_max_filesize для PHP.

Необходимо в файле конфигурации PHP установить данное значение выше 4Мб и перезапустить веб-сервер. В зависимости от окружения файл конфигурации PHP может находится в разных местах. Обычно данное значение устанавливается в файле /etc/php.ini.

Если вы используете панель ISPmanager — поправить конфигурацию можно прямо в ней: выберите нужный сайт, нажмите на кнопку PHP в верхней панели, найдите параметр upload_max_filesize и укажите нужное значение. Если вы используете окружение BitrixVM, необходимо вносить изменения в специальные файлы конфигурации, чтобы после перезагрузки сервера они не вернулись в исходное состояние. Подробнее можете узнать по ссылке.

Собственно журнал крон:

[root@b24 log]# tail -n 20 cron
Jul 24 17:23:01 b24 CROND[8929]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:23:01 b24 CROND[8930]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:24:01 b24 CROND[8937]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:24:01 b24 CROND[8938]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:25:01 b24 CROND[8946]: (root) CMD (/opt/webdir/bin/update_network.sh ens160)
Jul 24 17:25:01 b24 CROND[8947]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:25:01 b24 CROND[8948]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:26:01 b24 CROND[9048]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:26:01 b24 CROND[9049]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:27:01 b24 CROND[9061]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:27:01 b24 CROND[9062]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:28:01 b24 CROND[9074]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:28:01 b24 CROND[9075]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:29:01 b24 CROND[9084]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:29:01 b24 CROND[9085]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:30:01 b24 CROND[9100]: (root) CMD (/opt/webdir/bin/wrapper_ansible_conf -a check_network --update_log /opt/webdir/logs/update_pool.log 1>/dev/null 2>&1)
Jul 24 17:30:01 b24 CROND[9101]: (root) CMD (/opt/webdir/bin/update_network.sh ens160)
Jul 24 17:30:01 b24 CROND[9102]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jul 24 17:30:01 b24 CROND[9103]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jul 24 17:30:01 b24 CROND[9104]: (root) CMD (/usr/lib64/sa/sa1 1 1)

И при этом в журнале проверки системы Б24:

2023-Jul-24 17:15:08 Выполнение агентов на cron (check_bx_crontab): Fail
Ошибка! Не настроен запуск cron_events.php на cron, последний агент отработал больше суток назад.

Вот файл dbconn.php:

[root@b24 php_interface]# cat dbconn.php
<?
define("DBPersistent", false);
$DBType = "mysql";
$DBHost = "localhost";
$DBLogin = 'bitrix0';
$DBPassword = '***';
$DBName = "sitemanager";
$DBDebug = false;
$DBDebugToFile = false;

define("DELAY_DB_CONNECT", true);
define("CACHED_b_file", 3600);
define("CACHED_b_file_bucket_size", 10);
define("CACHED_b_lang", 3600);
define("CACHED_b_option", 3600);
define("CACHED_b_lang_domain", 3600);
define("CACHED_b_site_template", 3600);
define("CACHED_b_event", 3600);
define("CACHED_b_agent", 3660);
define("CACHED_menu", 3600);

define("BX_FILE_PERMISSIONS", 0644);
define("BX_DIR_PERMISSIONS", 0755);
@umask(~(BX_FILE_PERMISSIONS|BX_DIR_PERMISSIONS)&0777);

define("MYSQL_TABLE_TYPE", "INNODB");
define("SHORT_INSTALL", true);
define("VM_INSTALL", true);

define("BX_UTF", true);
if(!(defined("CHK_EVENT") && CHK_EVENT===true))
   define("BX_CRONTAB_SUPPORT", true);
define("BX_COMPRESSION_DISABLED", true);

define("BX_DISABLE_INDEX_PAGE", true);

define("BX_TEMPORARY_FILES_DIRECTORY", "/home/bitrix/.bx_temp/sitemanager/");

define("BX_USE_MYSQLI", true);
?>

Без вот этой строчки:
if(!(defined("CHK_EVENT") && CHK_EVENT===true))
всё то же самое.
При этом агенты НЕ запускаются…

Откуда ошибка лезет?

• #1

Добрый день! подскажите при тестировании решения в битрикс появляется предупреждение на шаге

Выполнение агентов на cron

Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron

Что означает предупреждение и что делать?

Последнее редактирование: 14.01.2021

• #2

Где это менять ?

Чтобы перенести работу непериодических агентов (и передачу почты) на cron, необходимо в /bitrix/php_interface/dbconn.php установить константу:
define('BX_CRONTAB_SUPPORT', true);
После этого на хитах будут выполняться только периодические агенты. Затем в cron поставить задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.php.
(замените /var/www на свой путь к корню сайта).
Внутри скрипта определена константа BX_CRONTAB, которая является индикатором того, что скрипт работает из cron и приводит к выполнению только непериодических агентов. Если эта константа ошибочно определена в dbconn.php, периодические агенты полностью перестают выполняться.

• #3

Где это менять ?

Чтобы перенести работу непериодических агентов (и передачу почты) на cron, необходимо в /bitrix/php_interface/dbconn.php установить константу:
define('BX_CRONTAB_SUPPORT', true);
После этого на хитах будут выполняться только периодические агенты. Затем в cron поставить задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.php.
(замените /var/www на свой путь к корню сайта).
Внутри скрипта определена константа BX_CRONTAB, которая является индикатором того, что скрипт работает из cron и приводит к выполнению только непериодических агентов. Если эта константа ошибочно определена в dbconn.php, периодические агенты полностью перестают выполняться.

Вот здесь по вашей проблеме

Запуск агентов из cron

Об агентах Агент может вносить ощутимое ожидание на хите пользователя. Но тут надо взвесить различные факторы. Например, агент выполняющийся 0.5 секунд раз в су…

dev.1c-bitrix.ru

• #4

Добрый день! подскажите при тестировании решения в битрикс появляется предупреждение на шаге

Что означает предупреждение и что делать?

если не мешает жить то не трогай

• #5

разобрался ок