knowledge-base/projects/buzharovo/server1c.md

date, type, tags

date	type	tags
2026-04-17	project	dttb

Server1C — Сервер 1С в Бужарово

Подключение

• Публичный IP: 185.13.47.2 (RDP:3389)
• Netbird IP: 100.70.75.103 (server1c.netbird.cloud)
• WinRM: порт 5985, basic auth
• Учётка: dttb / 1qaz!QAZ
• OS: Windows Server 2012 R2 (6.3.9600)
• Hostname: Server1C
• Локация: Бужарово

1С:Предприятие

Три службы агента:

1. 1C:Enterprise 8.3 Server Agent — StartType: Automatic
2. 1C:Enterprise 8.3 Server Agent (x86-64) — StartType: Automatic
3. RagentServer_8327 — версия 8.3.27.1606, StartType: Automatic

Решено: конфликт служб при загрузке (2026-04-16)

Проблема: 3 службы с Automatic стартовали одновременно, боролись за порты 1540/1541.

• Служба 8.3.18 (x86) — бинарник удалён, падала с ошибкой "файл не найден"
• RagentServer_8327 — дубликат без параметров, таймаут на портах
• Рабочая: 1C:Enterprise 8.3 Server Agent (x86-64) (8.3.27.1606)

Решение: отключены лишние службы (Disabled), оставлена только x86-64.

Решено: rmngr-loop после грязного ребута (2026-05-07)

Симптомы: утром локальные пользователи в Бужарово жалуются на резко тормозящую 1С. Удалённое подключение к 1С через NetBird ни при чём — проблема видна и в локальной сети.

Диагноз:

• Сервер ушёл в crash в 09:05 (Event 41 Kernel-Power: rebooted without cleanly shutting down + EventLog 6008: previous shutdown was unexpected).
• После загрузки rmngr.exe (менеджер кластера 1С) держит ~1.7 ядра постоянно вместо штатных <2% в idle. rphost, sqlservr, диски, сеть — в норме.
• rac.exe localhost:1540 cluster list отваливается с "ошибка соединения с сервером" — admin-канал rmngr повис, кластер не отвечает на управление.
• netbird.exe параллельно крутит 1.4 ядра — это reconnect-loop как побочка crash, после ребута сам приходит в норму.

Рецепт:

1. Замерить дельту CPU через Get-Process | %{$_.CPU} за 5 секунд — если у rmngr >50% одного ядра в idle, диагноз подтверждён.
2. Полный ребут сервера НЕ помогает — после загрузки rmngr опять начинает жрать CPU. На свежезагруженном сервере uptime=0.6 min: rmngr уже на 178% ядра.
3. Помогает рестарт службы: Restart-Service -Name '1C:Enterprise 8.3 Server Agent (x86-64)' -Force. После рестарта rmngr возвращается к 3% ядра. Все активные сеансы пользователей вылетят — нужно их предупредить.
4. После рестарта может остаться орфан-процесс ragent от прошлого старта (не слушает 1540, висит). Прибить вручную: Stop-Process -Id <pid> -Force.

Why: причина рута rmngr-loop неясна — возможно повреждение кэша srvinfo, регресс 8.3.27.1606, или Disabled-служба RagentServer_8327 мешает первому запуску ragent. Если повторится — смотреть C:\Program Files\1cv8\srvinfo\reg_*\1Cv8FTLog\ на ошибки.

Долгосрочно: настроить несколько rphost в кластере (по одному на 8-12 сеансов) — сейчас один rphost на всех локальных юзеров = бутылочное горлышко.

MS SQL Server (для server1c\RitmUl)

• Instance: localhost (default, MSSQL11 = SQL Server 2012 SP4)
• SA / Qwer1122334400 (полные права на все БД)
• БД: RitmUl (~3.8 GB), также есть Accounting, Retail_2021, Retail_2021demo
• Connection string: Server=localhost;Database=master;User Id=sa;Password=Qwer1122334400;

Бэкапы — native SQL, не Effector Saver

Канон от 2026-05-08: BACKUP DATABASE через SQL Server, не DT-выгрузка через Effector Saver. Подробности и причины — в decisions/2026-05-08-buzharovo-sql-native-backup.

Команда:

BACKUP DATABASE [RitmUl]
TO DISK = N'C:\backup\RitmUl_<timestamp>.bak'
WITH FORMAT, INIT, COMPRESSION, COPY_ONLY, STATS = 5

• Папка: C:\backup\ (на C: было 374 GB свободно на 2026-05-08)
• Время: ~2 сек на 3.8 GB БД
• Размер: ~30% от оригинала (3.8 GB → 1.1 GB сжатый)
• Online: не требует отключения пользователей, не требует cluster admin'а 1С
• Скрипт: /root/clawd/scripts/sql_native_backup.py на LXC 139 (severny-les bot)

Кластер 1С — известные проблемы

Cluster admin отсутствует, и его нельзя добавить

Серверная консоль 1С → Локальный кластер → Администраторы показывает 0, но при попытке создать через GUI требует логин cluster admin'а (которого нет) — chicken-and-egg. Через rac и V83.COMConnector — то же самое. Agent admin (создан 2026-05-08, admin/1qaz!QAZ на уровне (*)Server1C → Администраторы) не поднимает права на cluster operations.

Последствия:

• Effector Saver задача Бэкап 1Cv8 падает с Администратор кластера не аутентифицирован (HRESULT=80004005) → не может вызвать TerminateSession → не может получить эксклюзив на ИБ.
• Все cluster operations (просмотр сессий, kill сессий, блокировка соединений) недоступны через API.

Что НЕ помогло: SQL KILL сессий через sa — 1С rphost восстанавливает соединения за 1-2 мин, и persistent session_id (например КулябинПИ 4514 от 12:55:42 в день 2026-05-08) reanimate.

Workaround: SQL native backup (см. выше) — обходит всю эту историю с эксклюзивом.

Как лечить (не сделано, рискованно): обнулить C:\Program Files\1cv8\srvinfo\reg_1541\1CV8Clst.lst → потеряются и админы и регистрация ИБ → перерегистрировать ИБ через SQL params (SA/Qwer1122334400, host localhost, db RitmUl).

V83.COMConnector x64 зарегистрирован

2026-05-08 я через regsvr32 зарегистрировал C:\Program Files\1cv8\8.3.27.1606\bin\comcntr.dll в HKLM\SOFTWARE\Classes\V83.COMConnector (только x64; x86 платформа на сервере не установлена). В Effector Saver вручную переключено на "64-разрядный V83.ComConnector" → HRESULT=800401F3 ушёл.