Агенты не выполняются: письма не уходят, обмены не запускаются

Агенты — фоновые задачи продукта: отправка почты из очереди, обмен с 1С, пересчёты, очистка. Когда они встают, сайт продолжает работать, и проблему замечают не сразу — обычно по неотправленным письмам.

Сначала определите режим

Агенты запускаются либо на хите — при заходах посетителей, либо по расписанию через cron. От этого зависит, что проверять, а заодно и половина типовых поломок.

Режим задаётся настройкой главного модуля agents_use_crontab и константами в bitrix/php_interface/dbconn.php. Частая причина «агенты не работают» — переключение сделано наполовину: запуск на хите отключили, cron не настроили.

Если агенты на хите

1. Откройте список агентов в административной части: у каждого видно время следующего запуска. Даты в прошлом, которые не двигаются, — агенты встали.
2. Проверьте, активен ли сам агент: упавший с ошибкой снимается с выполнения.
3. Посмотрите журнал ошибок — упавший агент оставляет там след.
4. Оцените посещаемость: на сайте без трафика агенты на хите просто не запускаются, и ночные задачи не выполняются никогда.

Если агенты на cron

1. Есть ли задание. Проверьте расписание того пользователя, под которым работает сайт, а не только root.
2. Тот ли пользователь. Это главная ловушка — о ней ниже.
3. Правильный ли интерпретатор. На сервере несколько версий PHP; в задании версию указывают явно, иначе после смены версии задание тихо падает.
4. Права на файл обработчика в bitrix/php_interface/.
5. Настройки консольного PHP. У него свой файл настроек, и требования к нему те же, что к веб-версии.

Главная ловушка: cron под root

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

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

Правильно — ставить задание в расписание пользователя сайта. Если уже наступили, после смены пользователя нужно привести владельцев файлов кеша в порядок, иначе симптомы останутся.

Что ломается после перевода на cron

Перевод агентов на расписание — полезная операция, но у неё есть побочные эффекты, о которых узнают постфактум:

• Рассылки зависают. Письма остаются в статусе «отправляется» и не уходят даже при одном получателе: за отправку отвечает агент, которого теперь запускает cron, и если задание не работает, очередь стоит.
• Появляется сообщение о неотправленных письмах. Система честно пишет, что есть ошибки при отправке и сколько сообщений не ушло, — это индикатор, а не сама поломка.
• Скрипт запуска закрыт правами доступа. Если в конфигурации веб-сервера путь к обработчику закрыт от внешнего доступа, вызов через HTTP не сработает — нужен запуск через консольный PHP.

Как проверить, что всё работает

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

Проверяйте через сутки: часть агентов запускается редко, и «сразу после правки ничего не изменилось» — нормальная картина.

Частые ловушки

• Перенос сайта. Файлы и база переехали, задания расписания остались на старом сервере.
• Смена версии PHP. В задании указан интерпретатор, которого больше нет.
• Переключение режима наполовину — самый частый случай.
• Тяжёлый агент блокирует остальные. Импорт каталога, запущенный агентом, занимает очередь надолго; такие задачи выносят в отдельное задание расписания.