Ситуация, когда после обновления конфигурации 1С на сервере под управлением Linux (например, CentOS) система перестает пускать пользователей через толстый или тонкий клиент, — довольно распространенная проблема. При этом часто наблюдается странный симптом: через веб-браузер база открывается без проблем, а стандартная платформа выдает «Ошибка соединения с рабочим процессом». Разберем подробно, почему это происходит и как пошагово восстановить работоспособность системы.
Для начала проанализируем разницу в путях обращения к серверу 1С. Это поможет нам сузить круг поиска неисправности:
wsap24.so взаимодействует с кластером 1С локально. Если база открывается в браузере, значит, сам сервер 1С (процесс ragent) и процессы базы данных (rphost) запущены, а СУБД PostgreSQL исправна и отдает данные.Выясним причину: если веб-интерфейс работает, а платформа — нет, проблема кроется либо в сетевой доступности портов, либо в повреждении клиентского/серверного кэша, либо в специфических настройках разрешения имен (DNS/IP). Часто на Linux это связано с конфликтом IPv4 и IPv6, когда сервер начинает «слушать» порты только на IPv6.
Рассмотрим процедуру очистки кэша на Linux. В отличие от Windows, здесь важно соблюдать права доступа к директориям, чтобы служба смогла запуститься повторно. Выполним следующие действия:
1. Остановим службу сервера 1С:
systemctl stop srv1cv83
2. Проверим, не остались ли «зависшие» процессы rphost, rmngr или ragent. В Linux после сбоя обновления часто остаются «зомби-процессы», которые блокируют файлы. Принудительно завершим их:
killall -9 rphost
killall -9 rmngr
killall -9 ragent
3. Перейдем в директорию с данными сервера (по умолчанию это домашняя папка пользователя usr1cv8). Очистим содержимое временных папок. Будьте осторожны: не удаляйте файл 1CV8Reg.lst, если в нем прописаны настройки кластера, но удалите папки с длинными GUID-именами (это и есть кэш):
rm -rf /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/snccntx*
rm -rf /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/v8_*.tmp
4. После очистки обязательно проверим права доступа. Если вы случайно создали файлы под учетной записью root, 1С не сможет в них писать:
chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8
5. Снова запустим службу:
systemctl start srv1cv83
Если очистка кэша не помогла и проблема возникла именно в момент реструктуризации базы (например, из-за ошибки в коде, как в случае с некорректной сортировкой ТЗ.сортировать("Имя Возр")), нам потребуется вмешательство на уровне СУБД. Рассмотрим, какие таблицы отвечают за конфигурацию:
Config — основная конфигурация базы.ConfigSave — временная (сохраненная, но не обновленная) конфигурация.Params — параметры системы.Проанализируем ситуацию: если обновление «зависло», в таблице ConfigSave могут остаться некорректные данные, которые мешают платформе инициализировать метаданные. Попробуем сбросить состояние «незавершенного обновления»:
-- Очистка таблицы временной конфигурации (аналог отмены изменений в конфигураторе)
DELETE FROM ConfigSave;
-- Очистка таблицы изменений структуры
TRUNCATE TABLE DBChanges;
Если же конфигурация безнадежно испорчена, мы можем восстановить только «тело» конфигурации из резервной копии, не восстанавливая все данные (что значительно быстрее). Для этого в рабочей базе выполним замену данных в таблице Config данными из бэкапа:
TRUNCATE TABLE Config;
INSERT INTO Config SELECT * FROM [Имя_Базы_Копии].public.Config;
Посмотрим на ситуацию со стороны сети. Поскольку веб-клиент работает, Apache успешно «общается» с 1С внутри сервера. Но внешние клиенты (платформа на Windows) могут натыкаться на закрытые порты или неверное разрешение IP-адреса. Проверим порты на сервере Linux:
netstat -tulnp | grep 1541
Если вы видите, что порт слушается на адресе ::1 (IPv6), а не на 0.0.0.0 (IPv4), это и есть причина ошибки связи. Отредактируйте файл /etc/hosts, чтобы имя сервера было жестко привязано к его реальному IPv4-адресу:
192.168.1.10 myserver.domain.local myserver
Также проверьте настройки брандмауэра firewalld. При обновлении системы или перезагрузке правила могли сброситься. Нам нужно открыть диапазон портов для рабочих процессов:
firewall-cmd --permanent --add-port=1540-1591/tcp
firewall-cmd --reload
Иногда сервер 1С падает из-за критической ошибки в самой конфигурации, которая проявляется при попытке обращения к метаданным. Как было отмечено в обсуждении, ошибка в строке ТЗ.сортировать("Имя Возр") (где вместо корректного направления сортировки указана произвольная строка) может привести к непредсказуемому поведению рабочего процесса.
В этом случае, если зайти в Конфигуратор не удается, единственным выходом будет:
Подведем итог: если вы столкнулись с падением 1С на Linux после обновления, первым делом проверьте работоспособность веб-клиента. Если он жив — база данных в порядке, и вам нужно сосредоточиться на очистке серверного кэша /home/usr1cv8/.1cv8/ и проверке доступности портов 1541 и 1560-1591. Использование SQL-запросов к таблице ConfigSave является крайним, но эффективным методом при «зависшей» реструктуризации.