Каждый системный администратор или разработчик 1С рано или поздно сталкивается с ситуацией, когда сервер приложений начинает вести себя непредсказуемо. Одной из самых неприятных и труднодиагностируемых проблем является мёртвое зависание службы агента сервера 1С (ragent) при попытке её перезапуска. Служба переводится в состояние «Остановка» (Stopping) и замирает в нём навсегда. При этом сопутствующие процессы ragent.exe, rmngr.exe и rphost.exe невозможно принудительно завершить ни через «Диспетчер задач», ни с помощью консольной утилиты taskkill — система выдает ошибку «Нет доступа», а сервер приходится перезагружать аппаратно.
В этой статье мы подробно разберем, почему возникает эта критическая ситуация, как расшифровать загадочные «иероглифы» в логах технологического журнала (ТЖ) и какие практические шаги необходимо предпринять, чтобы навсегда решить проблему без перезагрузки физического сервера.
Как показывает практика, зависание службы не происходит мгновенно. Ему предшествует явный маркер деградации системы — полный отказ фоновых и регламентных заданий. Пользователи в базах данных могут продолжать работу (так как их сессии обслуживаются уже запущенными рабочими процессами), но новые фоновые задачи перестают инициироваться. Они не выдают ошибок, не записывают события в журнал регистрации и никак не реагируют на ручной запуск из консоли администрирования.
Попытка перезапустить службу сервера 1С в этот момент приводит к тому, что консоль служб Windows блокируется, а процессы зависают на уровне ядра операционной системы. Давайте разберемся, почему это происходит.
Если процесс невозможно убить даже с правами локального администратора (SYSTEM), это означает, что он ожидает завершения операции ввода-вывода (I/O) внутри драйвера режима ядра Windows. Операционная система не может завершить процесс до тех пор, пока драйвер не вернет управление. Чаще всего виновниками такого поведения становятся сетевые драйверы, брандмауэры, антивирусное ПО или некорректная работа сетевого стека сокетов.
Для понимания причин зависания нам потребуется включить технологический журнал. Рассмотрим конфигурационный файл logcfg.xml, который собирает необходимые события сетевого обмена (CONN), системных ошибок (EXCP) и процессов (PROC):
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump type="2" create="1" location="C:\1C_Info\Dumps"/>
<log location="C:\1C_Info\Logs" history="1">
<event><eq value="proc" property="name"/></event>
<event><eq value="scom" property="name"/></event>
<event><eq value="conn" property="name"/></event>
<event><eq value="admin" property="name"/></event>
<event><eq value="excp" property="name"/></event>
<event><eq value="qerr" property="name"/></event>
<property name="all"/>
</log>
</config>
При анализе полученных логов менеджер кластера (rmngr) часто фиксирует исключения, которые выглядят как нечитаемый набор символов (иероглифы):
51:08.550000-0,EXCP,1,process=rmngr,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='src\RHostImpl.cpp(2515):
81029657-3fe6-4cd6-80c0-36de78fe6657: ￎ￡￭￮ ￠￥￠￥ ￮... (иероглифы)'
Это классическая проблема несоответствия кодировок при выводе системных ошибок Windows в лог 1С. Если перевести эту системную ошибку из OEM-кодировки в ANSI, мы получим ключевую подсказку:
«Обычно разрешается только одно использование каждого адреса сокета (протокол/сетевой адрес/порт)».
В терминах Windows Sockets эта ошибка называется WSAEADDRINUSE (код ошибки 10048). Она сообщает, что менеджер кластера или рабочий процесс 1С пытается открыть сетевой порт, который уже занят другим процессом или удерживается операционной системой в состоянии ожидания.
Давайте проанализируем параметры запуска двух служб 1С (например, версий 8.2 и 8.3), работающих на одном физическом сервере:
ragent.exe -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\srvinfo_82"ragent.exe -srvc -agent -regport 1741 -port 1740 -range 1760:1791 -d "C:\srvinfo_83"На первый взгляд порты разделены корректно. Однако операционная система Windows имеет свой собственный пул динамических портов (Ephemeral Ports), которые она выделяет любым приложениям для исходящих соединений. По умолчанию в современных версиях Windows Server этот диапазон составляет порты с 49152 по 65535. Но в некоторых конфигурациях или старых ОС этот пул может начинаться от 1024.
Если динамические порты операционной системы пересекаются с диапазонами портов 1С (параметр -range), возникает конфликт. ОС выдает порт из диапазона 1С сторонней программе, после чего процесс rphost или rmngr не может инициализироваться, вызывая сбой сетевого обмена и зависание сокетов.
Чтобы избежать этого, настроим диапазон динамических портов Windows. Выполним в командной строке от имени Администратора:
netsh int ipv4 set dynamicport tcp start=49152 num=16384
Также ускорим освобождение закрытых сокетов, которые зависают в состоянии TIME_WAIT. Для этого откроем редактор реестра regedit, перейдем по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и создадим следующие параметры типа DWORD (32 бита):
30 (десятичное). Это сократит время удержания закрытого порта до 30 секунд (вместо стандартных 4 минут).65534 (десятичное). Это увеличит общее количество доступных пользователю портов.Современные сетевые адаптеры поддерживают технологии разгрузки процессора, передавая функции обработки пакетов непосредственно на сетевую плату (TCP Chimney Offload, Receive Side Scaling (RSS), Large Send Offload). Под высокой нагрузкой (которая всегда присутствует на серверах 1С и SQL) драйверы этих систем часто дают сбой, приводя к зависанию вспомогательного системного драйвера сокетов afd.sys. В результате сетевые потоки 1С блокируются на уровне ядра.
Выясним состояние сетевых оптимизаций и отключим их. Запустим командную строку от имени Администратора и выполним серию команд:
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global netdma=disabled
После этого зайдем в «Диспетчер устройств», откроем свойства нашего сетевого адаптера, перейдем на вкладку «Дополнительно» (Advanced) и переведем в состояние Disabled (Выключено) все параметры, содержащие в названии слова Offload, LSO, Checksum Offload.
Поскольку процессы 1С активно работают с сетью и временными файлами, антивирусы с включенными модулями сетевого экрана (брандмауэра) и поведенческого анализа часто перехватывают системные вызовы к сокетам. Если антивирусный драйвер блокирует сокет, процесс rphost зависает в бесконечном ожидании, а служба 1С уходит в бесконечную «Остановку».
Для решения этой проблемы настроим правила исключений в антивирусном продукте на сервере:
ragent.exermngr.exerphost.exesrvinfo).C:\Windows\Temp.Если на одном физическом сервере работают сразу несколько служб 1С (например, 8.2 и 8.3) и они запущены от имени разных пользователей (например, LocalSystem и USR1CV82), то они начинают конкурировать за права доступа к файлам в общей системной папке C:\Windows\Temp.
Например, процесс 8.2, запущенный под учетной записью локальной системы, создает во временном каталоге файл с монопольными правами. Процесс 8.3, запущенный от имени ограниченного пользователя USR1CV8, пытается обратиться к этой же директории или прочитать этот файл, получает отказ операционной системы и уходит в бесконечное ожидание блокировки, полностью парализуя работу кластера.
Чтобы избежать подобных коллизий, разделим временные каталоги для разных пользователей служб 1С:
C:\1C_Temp\User_82\C:\1C_Temp\User_83\TEMP и TMP для учетных записей пользователей 1С через свойства системы или через реестр Windows. Также можно прописать явные пути к временным каталогам в параметрах реестра запуска самой службы 1С.Еще одна неочевидная причина зависания сетевого взаимодействия кластера 1С — частичное отключение протокола IPv6. Очень часто администраторы просто снимают галочку «Протокол интернета версии 6 (TCP/IPv6)» в свойствах сетевого адаптера. При этом сам стек IPv6 в операционной системе остается активным, но перестает корректно маршрутизироваться.
Процессы 1С при обращении по адресу localhost или имени сервера начинают циклически обращаться к адресу локальной петли IPv6 ([::1]), не получают ответа от сетевой карты и зависают, пытаясь переподключиться.
Рекомендуется либо полностью включить IPv6 обратно, либо отключить его корректно через системный реестр Windows:
regedit и перейдем к ветке: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters.0xFFFFFFFF в шестнадцатеричной системе исчисления (или 4294967295 в десятичной).Мы подробно проанализировали причины мертвых зависаний серверов 1С при попытке перезапуска служб. Выяснилось, что первопричиной является исчерпание или блокировка сетевых сокетов на стыке взаимодействия платформы 1С и операционной системы.
Применяя комплексный подход — оптимизацию динамических портов Windows, отключение сетевых разгрузок (TCP Offloading), изоляцию временных папок TEMP и корректную настройку правил безопасности в антивирусе — мы гарантируем стабильную работу серверов 1С v8.2 и v8.3 без внезапных отказов фоновых заданий и зависаний служб.