При работе с платформой 1С:Предприятие версии 8.3.12.1595 системные администраторы часто сталкиваются с внезапным аварийным завершением процесса ragent. В операционных системах семейства Linux это сопровождается критической ошибкой Received signal 11. Terminating, что на языке системных вызовов означает Segmentation fault (ошибка сегментации). В технологическом журнале при этом наблюдается бесконечный цикл исключений EXCP с неописанными GUID и разрывы сетевых соединений NetDataExchangeException.
В этой статье мы подробно разберем, почему возникают эти ошибки, проанализируем записи технологического журнала и изучим пошаговый алгоритм стабилизации работы кластера 1С.
Одной из главных инноваций в ветке 8.3.12 стал переход на новый формат журнала регистрации, базирующийся на базе данных SQLite (файлы с расширением .lgp). По задумке разработчиков, это должно было ускорить поиск и выборку данных. Однако в первых релизах, включая 8.3.12.1595, механизм записи в SQLite оказался нестабильным при высоких нагрузках.
Рассмотрим ситуацию: когда несколько рабочих процессов rphost или сам ragent пытаются одновременно записать данные в журнал или прочитать их, возникают блокировки на уровне файловой системы. В определенных условиях это приводит к повреждению структуры базы SQLite или некорректному обращению к памяти, что и вызывает Signal 11. Мы видим в логах ошибку в модуле RemoteInterfaceImpl.cpp, которая прямо указывает на проблемы при десериализации данных или передаче пакетов между компонентами системы.
Наиболее эффективным и проверенным способом стабилизации платформы 8.3.12 является возврат к старому текстовому формату журнала регистрации (.lgf). Разберем, как это сделать правильно, чтобы не потерять данные и восстановить работоспособность службы.
Проанализируем шаги, необходимые для смены формата:
srv1cv83)./home/usr1cv8/.1cv8/1C/1cv8/conf/<UID-базы>/1Cv8Log/.1Cv8.lgp. Это и есть база SQLite. Рекомендуется переименовать его или переместить в архив.1Cv8.lgf.В конфигураторе 1С это можно сделать следующим образом: зайдите в меню Администрирование — Настройка журнала регистрации и выберите формат В текстовом файле. Если сервер падает и зайти в конфигуратор невозможно, используйте метод с подменой файлов, описанный выше.
Даже если мы переключили формат, остатки старого механизма могут мешать запуску. Проанализируем содержимое папки 1Cv8Log. Если там присутствуют файлы с расширениями -journal, -wal или -shm, их необходимо удалить. Эти файлы являются временными буферами SQLite, и если ragent упал в момент записи, они могут быть повреждены, блокируя последующие попытки инициализации интерфейса RemoteInterfaceImpl.
В логах автора темы часто встречается ошибка: Передача данных прервана по инициативе принимающей стороны. Это указывает на проблемы сетевого стека. Платформа 8.3.12 чувствительна к настройкам протокола IPv6. Часто ragent пытается установить связь через петлевой интерфейс (localhost) по IPv6, но политики безопасности ОС или настройки брандмауэра обрывают это соединение.
Разберем, как отключить IPv6 на уровне операционной системы Linux (например, Ubuntu или CentOS), чтобы исключить этот фактор:
# Открываем файл конфигурации sysctl
sudo nano /etc/sysctl.conf
# Добавляем в конец файла следующие строки:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
# Применяем изменения
sudo sysctl -p
После выполнения этих команд ragent будет принудительно использовать IPv4, что во многих случаях предотвращает NetDataExchangeException.
Падение с кодом Signal 11 может быть следствием выхода процесса за пределы выделенного ему стека. В версии 8.3.12.1595 наблюдались утечки памяти при передаче дескрипторов соединений. Выясним причину в настройках кластера.
Если у вас установлено большое количество информационных баз на одном процессе или слишком много соединений на один рабочий процесс, ragent может не справиться с диспетчеризацией. Попробуйте установить следующие параметры в консоли администрирования кластера:
Эти настройки заставят систему чаще создавать новые рабочие процессы rphost, что снизит нагрузку на ragent и уменьшит вероятность фатального сбоя всего кластера при ошибке в одном из потоков.
В обсуждении упоминается переход на PostgreSQL 10. Важно понимать, что полноценная поддержка этой версии СУБД была реализована в более поздних сборках 1С (начиная с 8.3.12.1640). Использование версии 1595 с 10-м Постгресом может приводить к ошибкам блокировок на уровне ядра СУБД, которые транслируются обратно в 1С как некорректные пакеты данных, вызывая падение агента.
Если обновление СУБД неизбежно, настоятельно рекомендуем обновить платформу 1С хотя бы до финального релиза ветки 8.3.12 (например, 8.3.12.1924) или перейти на более современные и стабильные ветки, такие как 8.3.18 или 8.3.22.
Подводя итог, мы можем сделать вывод, что основная причина нестабильности платформы 8.3.12.1595 кроется в "детских болезнях" нового журнала регистрации. Сочетание перехода на формат .lgf, отключение IPv6 и очистка временных файлов 1Cv8Log позволяют в большинстве случаев восстановить стабильную работу сервера без экстренного обновления всей системы. Проанализируйте состояние вашего сервера и последовательно примените указанные шаги для предотвращения аварийных завершений ragent.