← На главную

Аварийное отключение электропитания сервера — один из самых неприятных сценариев для системного администратора. Последствия внезапного отключения могут проявиться не сразу, а лишь после перезагрузки операционной системы и проведения автоматической проверки целостности дисков утилитой chkdsk. Одной из наиболее распространенных проблем в такой ситуации является внезапный отказ в работе сервера приложений 1С:Предприятие 8.3.

В данной статье мы подробно проанализируем ситуацию, когда служба агента сервера 1С (64-разрядная версия) успешно запускается в консоли служб Windows, однако при любой попытке пользователя или консоли администрирования подключиться к серверу, служба мгновенно завершает свою работу (падает). При этом клиент получает характерную ошибку соединения: descr=[::1]:1540:10061(0x0000274D):No connection could be made because the target machine actively refused it. Мы выясним, почему в этой ситуации 32-разрядный сервер работает без нареканий, детально разберем внутренние механизмы взаимодействия процессов 1С и рассмотрим пошаговые методы устранения этой неисправности.

Почему 32-битный сервер работает, а 64-битный падает?

Первое, что вызывает недоумение у многих специалистов — это ситуация, когда после удаления поврежденной 64-разрядной версии сервера и установки 32-разрядной версии система начинает функционировать абсолютно нормально. Повторная же установка 64-разрядной платформы снова приводит к падению службы. Разберем эту загадку подробнее.

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

• Для 64-разрядного сервера: C:\Program Files\1cv8\srvinfo
• Для 32-разрядного сервера: C:\Program Files (x86)\1cv8\srvinfo

При аварийном отключении питания файлы конфигурации кластера, находившиеся в этот момент в процессе записи, повреждаются. Когда операционная система Windows выполняет проверку файловой системы NTFS при загрузке, она пытается исправить поврежденные сектора. В результате файлы настроек в каталоге 64-разрядной версии (C:\Program Files\1cv8\srvinfo) оказываются либо усеченными до нулевого размера, либо заполняются некорректными бинарными данными.

Когда мы устанавливаем 32-разрядный сервер приложений, он обращается к абсолютно другому пути — C:\Program Files (x86)\1cv8\srvinfo. Данный каталог либо отсутствовал, либо не содержал поврежденных файлов. Соответственно, 32-битная служба создает чистую структуру настроек «с нуля» и успешно работает. При попытке вернуться на 64-разрядную версию, сервер вновь обращается к своей старой «битой» папке в Program Files, считывает поврежденные файлы конфигурации и аварийно завершает работу.

Глубокий анализ ошибки [::1]:1540:10061 и механика падения

Проанализируем сетевую ошибку, которую видит пользователь: descr=[::1]:1540:10061... No connection could be made because the target machine actively refused it.

Символ [::1] представляет собой IPv6-адрес локальной петли (loopback), эквивалентный адресу 127.0.0.1 в сетях IPv4. Порт 1540 — это стандартный порт агента сервера 1С (ragent.exe). Код ошибки socket-соединения 10061 (WSAECONNREFUSED) однозначно указывает на то, что сетевой порт закрыт или целевой хост активно отвергает подключение.

Как это происходит на уровне процессов?

1. Служба Windows «Агент сервера 1С:Предприятия 8.3» запускает процесс ragent.exe. На данном этапе процесс успешно стартует и начинает слушать порт 1540.
2. При попытке подключения клиента или консоли администрирования, процесс ragent.exe считывает конфигурационные файлы кластера из папки srvinfo, чтобы определить параметры рабочих процессов и инициализировать менеджер кластера rmngr.exe.
3. Так как файлы конфигурации (например, 1cv8wsrv.lst или 1CV8Clst.lst) повреждены или содержат неконсистентные данные, процесс rmngr.exe (или рабочий процесс rphost.exe) падает сразу после запуска или вообще не может инициализироваться.
4. Потеряв связь со своими дочерними процессами, главный процесс ragent.exe переходит в аварийный режим, завершает свою работу и закрывает порт 1540.
5. Клиентское приложение, пытающееся завершить соединение по протоколу TCP, получает отказ, поскольку порт службы закрылся из-за ее падения.

Пошаговые алгоритмы решения проблемы

Рассмотрим подробнее несколько практических вариантов восстановления работоспособности 64-разрядного сервера 1С в зависимости от степени повреждения данных кластера.

Вариант А. Безопасная очистка кэша сеансов

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

1. Остановим службу агента сервера 1С. Для этого откроем оснастку «Службы» (services.msc), найдем службу «Агент сервера 1С:Предприятия 8.3 (x86-64)» и нажмем «Остановить».
2. Откроем Диспетчер задач Windows и проверим вкладку «Процессы». Нам необходимо убедиться, что в системе не осталось зависших процессов ragent.exe, rmngr.exe и rphost.exe. Если они присутствуют, завершим их принудительно.
3. Перейдем в каталог данных кластера: C:\Program Files\1cv8\srvinfo.
4. Зайдем в папку конкретного кластера. По умолчанию она называется reg_1541 (номер порта может отличаться в вашей системе).
5. Найдем внутри папку, имя которой начинается на snccntx (это каталог кэша данных сеансов) и полностью удалим её.
6. Удалим все файлы с расширением *.tmp в каталоге reg_1541.
7. Важно: не трогайте файлы 1cv8wsrv.lst и 1CV8Clst.lst, так как именно в них содержится список ваших информационных баз и параметры их подключения к SQL-серверу.
8. Запустим службу 1С обратно и попробуем подключиться к консоли. Если проблема была в сеансовых файлах, сервер успешно заработает.

Вариант Б. Полное пересоздание кластера серверов 1С

Если предыдущий вариант не помог, значит, повреждены сами файлы описания кластера. В этом случае лучшим решением будет полное пересоздание структуры кластера. Обратите внимание, что базы данных, размещенные на MS SQL Server или PostgreSQL, при этом абсолютно не пострадают — мы лишь сбросим настройки их регистрации в кластере 1С.

1. Остановим службу 1С через консоль служб Windows.
2. Перейдем в папку C:\Program Files\1cv8\.
3. Переименуем каталог srvinfo, например, в srvinfo_old. Это позволит нам сохранить резервную копию старых настроек, из которой в дальнейшем можно будет подсмотреть параметры подключения к базам.
4. Запустим службу «Агент сервера 1С:Предприятия 8.3».
5. Платформа обнаружит отсутствие каталога srvinfo и автоматически создаст новую чистую структуру папок и файлов конфигурации по умолчанию. При этом служба запустится без каких-либо ошибок.
6. Запустим консоль администрирования серверов 1С. Теперь она успешно подключится к локальному кластеру.
7. Нам остается лишь заново зарегистрировать (добавить) наши информационные базы в созданный кластер. Для этого щелкнем правой кнопкой мыши по разделу «Информационные базы», выберем «Создать» -> «Информационная база» и укажем параметры подключения к СУБД (имя сервера баз данных, имя базы данных и учетные данные), которые использовались ранее.

Вариант В. Восстановление прав доступа файловой системы NTFS

Работа утилиты chkdsk по исправлению ошибок файловой системы часто сопровождается сбросом или повреждением списков контроля доступа (ACL) к файлам и папкам. Если служба 1С не имеет прав на запись в свою же служебную директорию, она не сможет инициализировать файлы блокировок и упадет при первом же клиентском запросе.

1. Выясним, от имени какого пользователя запускается служба 1С. По умолчанию в современных версиях платформы используется локальный пользователь USR1CV8. Это можно проверить в свойствах службы на вкладке «Вход в систему».
2. Откроем проводник Windows и перейдем в свойства папки C:\Program Files\1cv8\srvinfo.
3. Перейдем на вкладку «Безопасность» и нажмем кнопку «Изменить» (или «Дополнительно»).
4. Проверим наличие пользователя USR1CV8 (или другого пользователя, от имени которого работает служба) в списке разрешений.
5. Убедимся, что для данного пользователя установлен флаг «Полный доступ» (Full Control).
6. Нажмем кнопку «Дополнительно», выберем пункт «Заменить все записи разрешений дочернего объекта наследуемыми от этого объекта» и нажмем «Применить», чтобы права принудительно распространились на все файлы конфигурации и вложенные папки внутри srvinfo.

Вариант Г. Отключение протокола IPv6 на уровне операционной системы

Иногда сбой сетевого стека Windows приводит к тому, что сокеты IPv6 начинают работать некорректно, вызывая ошибку [::1]:1540. Простое снятие галочки «Протокол интернета версии 6 (TCP/IPv6)» в свойствах сетевого адаптера не отключает IPv6 для локального адреса loopback (localhost) в ядре ОС. Для полного отключения IPv6 проделаем следующие шаги:

1. Запустим редактор реестра, нажав сочетание клавиш Win + R, введя команду regedit и нажав Enter.
2. Перейдем к следующему разделу реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
3. В правой панели проверим наличие параметра типа DWORD (32 бита) с именем DisabledComponents. Если его нет, создадим его вручную (Правый клик -> Создать -> Параметр DWORD (32 бита)).
4. Дважды кликнем по параметру DisabledComponents, выберем шестнадцатеричную систему исчисления (Hexadecimal) и установим значение равным ffffffff (восемь символов f). Пример импортируемого REG-файла представлен ниже:
Скопировать код

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"DisabledComponents"=dword:ffffffff

5. Нажмем ОК и перезагрузим операционную систему для применения изменений сетевого стека.

После перезагрузки операционная система Windows Server будет полностью использовать исключительно протокол IPv4, что исключит любые сетевые конфликты, связанные с адресацией IPv6 на локальном хосте.

Заключение и превентивные рекомендации

Мы детально разобрали причины, по которым 64-разрядный агент сервера приложений 1С падает при подключении клиентов после некорректного выключения сервера. Наиболее эффективным решением в большинстве случаев является полное пересоздание структуры кластера (Вариант Б) или очистка сеансовых данных (Вариант А).

Чтобы минимизировать риски возникновения подобных инцидентов в будущем, мы рекомендуем придерживаться следующих правил:

• Использование ИБП: Обязательно подключайте физические серверы баз данных и приложений 1С к качественным источникам бесперебойного питания (ИБП) с настроенным софтом автоматического корректного завершения работы Windows при исчерпании заряда батареи.
• Резервное копирование srvinfo: Настройте регулярное резервное копирование не только баз данных SQL, но и каталога служебных настроек 1С (папки srvinfo). Наличие актуальной резервной копии этой папки позволит восстановить список сотен баз в кластере за считанные секунды без необходимости их ручного добавления в случае сбоя.