Администрирование серверов на базе Linux требует аккуратности, особенно когда речь идет о высоконагруженных системах СУБД и серверах приложений «1С:Предприятие». Довольно распространенной является ситуация, когда на системном диске внезапно заканчивается свободное место, и администратор (или обслуживающий программист) в спешке начинает удалять временные файлы, логи и кэш. Если очистка выполняется некорректно, система может ответить критическим сбоем при попытке запустить информационную базу. Одной из самых загадочных ошибок в таких случаях становится сообщение: «Ошибка при выполнении операции с информационной базой. Ошибка загрузки компоненты 'help'. Файл не обнаружен».
В этой статье мы подробно разберем, почему возникает данная ошибка, как она связана с системным каталогом /tmp, правами доступа в Linux и запуском СУБД PostgreSQL, а также рассмотрим пошаговый алгоритм диагностики и восстановления работоспособности сервера.
Вопреки своему названию, компонента help отвечает в платформе «1С:Предприятие» не только за вывод стандартной справочной системы по клавише F1. Это базовая низкоуровневая компонента ядра платформы. Она участвует в инициализации интерактивных процессов, обработке локализованных ресурсов, форматировании интерфейса и динамической подгрузке библиотек во временные директории при старте сеанса.
Когда сервер 1С или клиентское приложение инициализирует рабочее окружение, платформа пытается распаковать свои служебные динамические библиотеки во временный каталог операционной системы (в случае Linux — это /tmp или подкаталоги внутри /var/tmp). Если этот процесс прерывается из-за нехватки прав, отсутствия папок или блокировок файловой системы, платформа не находит нужный файл библиотеки и выдает ошибку загрузки компоненты help.
При агрессивной ручной очистке диска с помощью команд типа rm -rf /tmp/* под учетной записью суперпользователя root часто совершается критическая ошибка — сбрасываются права доступа на саму директорию /tmp или она удаляется целиком и создается заново с дефолтными правами.
В операционных системах семейства Linux (CentOS, RedHat, Ubuntu, Debian) каталог /tmp имеет особый статус. Для его корректной работы должны быть соблюдены строгие правила:
root и группа root.1777. Четверка в начале (или символ t в конце строки прав drwxrwxrwt) означает так называемый Sticky Bit (липкий бит).Липкий бит (Sticky Bit) гарантирует, что любой пользователь системы (включая служебных пользователей usr1cv8 для 1С и postgres для СУБД) может создавать, читать и записывать файлы в каталоге /tmp, но удалять или переименовывать чужие файлы внутри этой папки может только их непосредственный владелец или root. Если этот бит сброшен или права на папку установлены, например, как обычные 755 или даже 777 без Sticky Bit, службы СУБД PostgreSQL и сервера 1С теряют возможность корректно создавать свои сокеты, файлы блокировок и временные файлы сессий. В результате СУБД останавливается, а 1С выдает ошибку загрузки базовых компонент.
Давайте по шагам пройдем процесс восстановления работоспособности сервера после некорректной очистки диска.
Прежде чем приступать к исправлению прав, убедимся, что на диске действительно физически освободилось место. Для этого выполним команду просмотра дискового пространства:
df -h
Также крайне важно проверить количество свободных индексных дескрипторов (inodes). В Linux каждый файл занимает один дескриптор. Если на сервере 1С генерировалось огромное количество мелких файлов кэша или сессий, лимит inodes мог исчерпаться, даже если утилита df -h показывает свободные гигабайты. Проверим inodes командой:
df -i
Если процент использования системного раздела равен 100%, операционная система не сможет создать ни одного нового файла, что также приведет к сбою компоненты help.
Выясним, запущены ли ключевые службы нашего сервера. Для этого используем стандартные команды управления службами (в зависимости от версии вашей ОС CentOS/Ubuntu):
# Для современных дистрибутивов с systemd:
systemctl status postgresql
systemctl status srv1cv83
# Для устаревших систем (например, CentOS 6):
service postgresql status
service srv1cv83 status
Если служба PostgreSQL остановлена или находится в состоянии сбоя (failed), то сервер 1С не сможет подключиться к базам данных. Очень часто СУБД падает именно из-за невозможности создать файл сокета в каталоге /tmp.
Посмотрим, какие права установлены на временную директорию сейчас. Выполним команду:
ls -ld /tmp
В нормальном состоянии вывод команды должен выглядеть следующим образом:
drwxrwxrwt. 10 root root 4096 Oct 24 12:00 /tmp
Если вы видите, что владельцем папки стал другой пользователь (например, usr1cv8), отсутствуют права на запись для всех категорий пользователей или пропал флаг t (в конце прав отображается просто rwxrwxrwx или rwxr-xr-x), необходимо срочно вернуть исходные параметры безопасности.
Для восстановления правильного владельца и прав выполним под учетной записью администратора следующие команды:
sudo chown root:root /tmp
sudo chmod 1777 /tmp
После этого повторно проверяем права через ls -ld /tmp и убеждаемся, что права установлены корректно (строка начинается с drwxrwxrwt).
После того как права на временную папку были восстановлены, необходимо последовательно перезапустить СУБД и сервер приложений 1С:
# Перезапуск СУБД PostgreSQL
sudo systemctl restart postgresql
# Перезапуск сервера 1С
sudo systemctl restart srv1cv83
Если вы используете CentOS 6, команды будут следующими:
sudo service postgresql restart
sudo service srv1cv83 restart
После успешного перезапуска служб попробуйте запустить клиентское приложение 1С или войти в консоль администрирования серверов. Ошибка загрузки компоненты help должна исчезнуть.
Если восстановление прав на /tmp не решило проблему полностью, проанализируем еще два важных аспекта.
В дистрибутивах CentOS по умолчанию включена система принудительного контроля доступа SELinux. Если во время очистки каталог /tmp был физически удален и создан вручную заново, он мог получить неверный контекст безопасности. В результате SELinux будет блокировать любые попытки процессов СУБД и 1С выполнять запись или исполнение бинарных кодов из этой папки.
Для проверки временно переведем SELinux в разрешающий (permissive) режим:
sudo setenforce 0
Если после этого 1С успешно запустилась, значит, дело в контекстах безопасности. Восстановим правильный контекст для папки /tmp командой:
sudo restorecon -R -v /tmp
После восстановления контекста можно вернуть SELinux в исходный защищенный режим работы командой sudo setenforce 1.
Как упоминалось в исходном обсуждении на форуме, при очистке диска были случайно удалены папки локализации. Если операционная система теряет дефолтную локаль (например, ru_RU.UTF-8), сервер 1С не сможет корректно инициализировать сеанс, что по цепочке вызовет сбой работы базовых компонент пользовательского интерфейса.
Проверим текущие настройки локали в системе:
locale
Если вывод команды пуст или содержит ошибки, необходимо сгенерировать русскую локаль заново и применить её в системе. Для CentOS/RHEL это делается следующими командами:
sudo localedef -v -c -i ru_RU -f UTF-8 ru_RU.UTF-8
export LANG=ru_RU.UTF-8
Чтобы избежать подобных аварийных ситуаций в будущем, необходимо отказаться от бесконтрольного ручного удаления файлов из системных папок. Рассмотрим несколько лучших практик обслуживания дискового пространства сервера 1С.
Вместо опасной команды rm -rf /tmp/* используйте системную утилиту tmpwatch (в CentOS) или tmpreaper (в Ubuntu/Debian). Эти утилиты безопасно удаляют только те файлы, к которым никто не обращался в течение заданного времени (например, последние 10 дней), не затрагивая при этом активные сокеты запущенных служб и структуру прав:
# Очистить файлы в /tmp, к которым не обращались более 240 часов (10 дней)
sudo tmpwatch 240 /tmp
Основным «пожирателем» свободного места на серверах 1С часто выступает журнал регистрации (файлы с расширением *.lgp или база данных журнала 1Cv8.lgd).
Для безопасного уменьшения их объема выполните следующие действия:
sudo service srv1cv83 stop./home/usr1cv8/.1cv8/1C/1cv8/reg_XXXX/XXXX/1Cv8Log/.sudo service srv1cv83 start.Еще один крупный источник временных файлов — индекс полнотекстового поиска (ППС). Если дисковое пространство критически мало, временно отключите регламентное задание «Обновление индекса ППС» в базах 1С, после чего можно физически удалить файлы индекса из папки базы данных на сервере. При необходимости индекс будет перестроен автоматически при повторном включении задания.
Чтобы переполнение системного раздела /tmp не приводило к отказу операционной системы, рекомендуется вынести временные файлы сервера 1С на отдельный быстрый SSD-накопитель большой емкости.
Для этого создайте новую директорию, например, /mnt/fast_ssd/1c_temp, назначьте ее владельцем пользователя usr1cv8:
sudo mkdir -p /mnt/fast_ssd/1c_temp
sudo chown -R usr1cv8:grp1cv8 /mnt/fast_ssd/1c_temp
sudo chmod 770 /mnt/fast_ssd/1c_temp
Затем откройте конфигурационный файл службы сервера 1С (в CentOS он находится по пути /etc/sysconfig/srv1cv83, в Debian/Ubuntu — /etc/default/srv1cv83) и добавьте или измените переменные окружения, указывающие на новый путь для временных файлов:
export TEMP=/mnt/fast_ssd/1c_temp
export TMP=/mnt/fast_ssd/1c_temp
После перезапуска сервера 1С все временные кэши будут создаваться в изолированной папке на выделенном диске, гарантируя стабильность операционной системы.