При работе связки Ubuntu 18.04, 1С:Предприятие 8.3 и PostgreSQL системные администраторы часто сталкиваются с ситуацией, когда база данных внезапно перестает принимать подключения. Пользователи получают ошибку о недоступности сервера по TCP/IP на порту 5432, а стандартные проверки показывают, что процесс базы данных отсутствует в списке активных, хотя служба числится запущенной. Рассмотрим подробнее, почему это происходит и как вернуть систему в рабочее состояние.
В первую очередь проверим доступность порта 5432. Если при использовании команды telnet или ss -tunpl | grep 5432 мы не видим активных прослушиваемых сокетов, значит, PostgreSQL фактически не запустился. Однако команда sudo service postgresql status может выдать обманчивый результат:
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2019-08-28 20:32:31 +06; 1h 11min ago
Process: 1081 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Здесь мы видим статус active (exited) и выполнение /bin/true. Разберем, что это значит. В ОС семейства Ubuntu пакет PostgreSQL использует систему «мета-сервисов». Основной сервис postgresql.service не является самой базой данных; он лишь запускает скрипт, который должен инициировать работу конкретных кластеров. Если кластер не сконфигурирован или поврежден, мета-сервис сообщит об успешном запуске «пустышки», в то время как сама СУБД будет лежать.
Для диагностики реального состояния кластеров воспользуемся специализированной утилитой:
pg_lsclusters
Если в столбце Status вы видите значение down, значит, кластер остановлен из-за критической ошибки.
Проанализируем ситуацию, описанную в логах системы. Основная причина внезапной поломки — автоматическое обновление пакетов Ubuntu (unattended-upgrades). Стандартные репозитории Ubuntu содержат «ванильную» версию PostgreSQL. Версия же, необходимая для работы 1С, содержит специфические патчи (поддержка ICU, особенности блокировок и пр.).
Когда система видит в официальном репозитории Ubuntu версию PostgreSQL с более высоким номером билда, она автоматически заменяет вашу пропатченную версию на стандартную. Стандартный бинарный файл postgres часто не может запустить базу, созданную пропатченной версией, из-за несовместимости параметров в postgresql.conf или различий в структуре данных.
Посмотрим на логи в каталоге /var/lib/postgresql/10/main/pg_log/. Часто там встречается ошибка: ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8". Это происходит потому, что PostgreSQL пытается использовать локали, которые не сгенерированы в самой операционной системе.
Для решения этой проблемы выполним принудительную генерацию необходимых локалей. Пошагово это выглядит так:
locale -a.ru_RU.utf8 или en_US.utf8 отсутствуют, выполним их генерацию:
sudo locale-gen ru_RU.UTF-8
sudo locale-gen en_US.UTF-8
sudo update-locale
Если обновление уже произошло и база не запускается, нам необходимо вернуть правильные исполняемые файлы. Рассмотрим алгоритм восстановления:
Шаг 1: Сохранение данных. Перед любыми манипуляциями обязательно создайте резервную копию каталога данных. По умолчанию в Ubuntu 18.04 это /var/lib/postgresql/10/main.
Шаг 2: Удаление «ванильного» пакета. Удалите установленный из стандартных репозиториев PostgreSQL, стараясь не затронуть файлы конфигурации и данных (используйте apt-get remove вместо purge, если уверены в путях).
Шаг 3: Установка версии от 1С. Установите пакеты postgresql-10, postgresql-client-10 и postgresql-common, загруженные с портала 1С или из доверенного репозитория (например, Postgres Professional).
Шаг 4: Фиксация версии. Чтобы ситуация не повторилась при следующем обновлении системы, необходимо запретить обновление этих пакетов. Выполним команду apt-mark hold:
sudo apt-mark hold postgresql-10
sudo apt-mark hold postgresql-client-10
sudo apt-mark hold postgresql-common
Теперь система будет игнорировать обновления этих компонентов, и ваша база данных будет в безопасности.
Проанализируем еще один важный аспект — права доступа к сокету. В первом сообщении упоминалась ошибка could not connect to server: No such file or directory по пути /var/run/postgresql/.s.PGSQL.5432.
Проверим, кто является владельцем этой директории. После переустановки пакетов права могут сброситься. Владельцем должен быть пользователь postgres. Также убедимся, что в файле postgresql.conf параметр unix_socket_directories указывает на верный путь:
unix_socket_directories = '/var/run/postgresql'
Если вы только настраиваете сервер или решили начать «с чистого листа», используйте правильную инициализацию. Для 1С критически важно, чтобы база была создана с поддержкой русской локали. Разберем пример команды инициализации:
sudo su postgres
/usr/lib/postgresql/10/bin/initdb -D /var/lib/postgresql/10/main --locale=ru_RU.UTF-8
Важный момент: если в логах вы видите ошибку ALERT USER postgres WITH PASSWORD 'password', помните, что это синтаксическая ошибка. Правильная команда для смены пароля в консоли psql — ALTER USER.
Подведем итог. Если ваш PostgreSQL на Ubuntu перестал работать:
pg_lsclusters.ru_RU.UTF-8 и en_US.UTF-8.apt-mark hold./var/lib/postgresql и /var/run/postgresql.Соблюдение этих шагов позволит вам создать стабильную среду для работы 1С:Предприятие на Linux и избежать внезапных простоев из-за автоматических системных обновлений. Для поддержания стабильности при обслуживании нескольких информационных баз применяется автоматическое архивирование, обновление и тестирование баз 1С в тихом режиме по расписанию.