Ситуация, когда на сервере под управлением Linux внезапно заканчивается свободное место, является критической для системы 1С:Предприятие. Даже после того как место было освобождено, служба часто не возвращается в рабочее состояние: процессы ragent и rmngr могут запускаться, но основной рабочий процесс rphost либо отсутствует в списке запущенных, либо постоянно перезапускается. В логах при этом часто фигурирует ошибка Connection refused по адресу 127.0.1.1:1541.
В этой статье мы подробно разберем, почему это происходит, как диагностировать проблему и какими способами можно восстановить работоспособность сервера. При проектировании защищенной IT инфраструктуры на Astra Linux важно учитывать такие сценарии заранее.
Прежде чем приступать к активным действиям, нам необходимо выяснить текущее состояние процессов сервера 1С. В среде Linux основным инструментом для этого является утилита systemctl и команда ps. Рассмотрим типичную ситуацию, когда служба формально запущена, но фактически не работает.
Проверим статус службы с помощью команды:
systemctl status srv1cv8-8.3.24.1548@default.service
Если в поле Active мы видим статус active (running), но время работы (since) постоянно сбрасывается (не превышает 30-60 секунд), это явный признак «циклической перезагрузки». Главный процесс ragent пытается запустить вспомогательные процессы, они падают из-за поврежденных данных, и цикл повторяется. Проанализируем список запущенных процессов от имени пользователя 1С:
sudo ps -fU usr1cv8
В нормальной ситуации мы должны увидеть цепочку: ragent -> rmngr -> rphost. Если rphost отсутствует, значит, менеджер кластера не может инициализировать рабочие процессы. Одной из частых причин является повреждение индексных файлов или журналов в каталоге кластера в тот момент, когда 1С пыталась записать данные на переполненный диск.
Если сервер необходимо запустить максимально быстро и вы готовы заново добавить информационные базы в консоль администрирования, наиболее эффективным методом будет полная очистка каталога сервера 1С. Рассмотрим этот процесс по шагам.
sudo systemctl stop srv1cv8-8.3.24.1548@default.service
/home/usr1cv8/.1cv8/1C/1cv8. Проанализируем содержимое этой папки..1cv8, но помните, что это приведет к потере настроек кластера (списка баз, администраторов).
rm -rf /home/usr1cv8/.1cv8/*
sudo systemctl start srv1cv8-8.3.24.1548@default.service
После этих действий сервер создаст чистую структуру папок. Вам потребуется заново создать кластер и добавить в него информационные базы, указав пути к существующим базам на SQL-сервере. Не забудьте также выполнить регламентное обслуживание баз данных 1C на Postgresql.
Если удалять весь кластер нежелательно, попробуем выяснить причину сбоя точечно. Часто проблема кроется в поврежденных файлах журналов регистрации процессов rtrsrvc или индексах полнотекстового поиска. Проанализируем структуру папки reg_1541.
Внутри каталога /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 находятся папки с GUID информационных баз. Одной из причин «раздувания» дискового пространства и последующего падения является файл tableChanges.dat, расположенный в подпапке 1Cv8FTxt.
Разберем алгоритм безопасной очистки:
1Cv8FTxt. Если файл tableChanges.dat занимает гигабайты, именно он мог стать причиной нехватки места.snccntx* (сеансовые данные) и временные файлы журналов.reg_1541 присутствуют файлы с расширением .lgd или .lgp, которые выглядят поврежденными (имеют нулевой размер или заполнены некорректными символами), их также стоит переместить в архив или удалить.Файл tableChanges.dat — это очередь регистрации изменений для полнотекстового поиска (ПП). Если полнотекстовый поиск в базе включен, но регламентное задание по обновлению индекса не выполняется (или выполняется слишком редко), этот файл будет расти бесконечно.
Проанализируем меры профилактики:
Обновление индекса полнотекстового поиска выполняется каждые несколько минут.8.3.24.1808 наблюдались ошибки, при которых файл tableChanges.dat рос аномально быстро. Также настройте регулярное архивирование баз данных PostgreSQL, чтобы иметь возможность отката при сбоях.Иногда корень проблемы кроется в настройках самого сервера Linux или параметрах запуска службы. Проанализируем влияние отладки на стабильность. Если сервер запущен с ключом -debug, это создает дополнительную нагрузку на подсистему передачи данных.
Чтобы отключить режим отладки, выполним следующие действия:
/etc/systemd/system/srv1cv8... или файл окружения в /etc/default/srv1cv8...).SRV1CV8_DEBUG и убедитесь, что он пуст или закомментирован.
systemctl daemon-reload
systemctl restart srv1cv8-8.3.24.1548@default.service
Также обратим внимание на ошибку DataExchangeTcpClientImpl.cpp. Она часто возникает, когда система пытается разрешить имя хоста через IPv6, в то время как 1С настроена на IPv4. Проверим файл /etc/hosts. Если там указана строка типа 127.0.1.1 server1c, попробуйте заменить её на реальный IP-адрес сервера или убедиться, что localhost резолвится корректно. В некоторых случаях помогает полное отключение IPv6 в параметрах ядра Linux.
Выясним ещё одну специфическую для Linux причину. Иногда команда df -h показывает наличие свободного места, но 1С все равно не может создать файл. Это происходит, когда заканчиваются inodes (индексные дескрипторы) из-за огромного количества мелких файлов (например, временных файлов сессий или логов).
Проверим состояние дескрипторов:
df -i
Если значение IUse% приближается к 100%, никакая очистка «веса» файлов не поможет — нужно удалять именно количество файлов. В 1С это чаще всего лечится очисткой каталогов /tmp и папок snccntx в кластере.
Подводя итог, можно сказать: наиболее надежный способ быстро вернуть сервер в строй после переполнения диска — это удаление содержимого каталога .1cv8. Однако для долгосрочного решения необходимо следить за состоянием индексов полнотекстового поиска и настроить мониторинг свободного места (например, через Telegram-бот для мониторинга дисков), чтобы не допускать критического заполнения файловой системы.