Создание базы 1с postgre ошибка

При работе с 1С в клиент-серверном варианте могут возникать ошибки, которые напрямую не связаны с 1С:Предприятием, а связаны непосредственно с сервером управления баз данных.

Одна из распространенных ошибок — «Сервер баз данных не обнаружен…».

Продолжение данного сообщения может быть различным:

1. 1. Could not translate host name «NAME» to address: Temporary failure in name resolution

   2. ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

   3. ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»

   4. Is the server running on host and accepting TCP/IP connections on port 5432?

   5. «Породить новый процесс для соединения не удалось: Ресурс временно недоступен» или «ВАЖНО: извините, уже слишком много клиентов.»

   6. FATAL: database «base» does not exist

Далее рассмотрим подробнее каждую ошибку.

Could not translate host name «NAME» to address: Temporary failure in name resolution

Пример полного текста ошибки:

Описание:

Ошибка может возникать как при создании базы, так и при запуске информационной базы.

Решение:

Настроим DNS-адресацию или пропишем адреса в файл hosts. Обратите внимание, что в данном случае проблема в том, что на сервере 1С нет информации о доменном имени сервера СУБД PostgreSQL. Подробнее о DNS — Настройка DNS-адресации для 1С сервера.

ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Пример полного текста ошибки:

Описание: Ошибка возникает при создании базы.

Решение:

Настроим проверку подлинности.

1. 1. Сконфигурируем доступ к серверу PostgreSQL в файле: pg_hba.conf:

Файл должен содержать только следующие строки (содержащие ip серверов 1С) (остальные удалим или пометим как комментарий):

Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.

Последняя колонка указывает на метод авторизации.

Если пока теряетесь в настройках доступа. Для понимания, можно сначала открыть все, запустить сервер.

А после удачного старта сервера СУБД разбираться с настройками доступа.

ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»

Пример полного текста ошибки:

Описание ошибки:

Ошибка связана с отсутствием прописанного доступа к базе данных в файле pg_hba.conf

Решение:

Добавим запись в файл pg_hba.conf.

Приведем пример содержания файла, который открывает доступ:

Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.

Is the server running on host and accepting TCP/IP connections on port 5432?

Пример полного текста ошибки:

Описание:

Проблема может возникать как при создании информационной базы из консоли администрирования 1С: Предприятия, так и при ее запуске в процессе эксплуатации уже существующей базы данных.

Решение:

В данном случае необходимо понимать, что рабочего процесса:

Либо нет;

Либо клиент(в нашем случае сервер 1С) его не «видит» по ряду причин:

— Отсутствие доступа;

— Обращение по другому адресу.

1. Первоначально, конечно, проверим, есть ли на сервере СУБД PostgreSQL в запущенных процессах процесс postmaster/postgres (в зависимости от версии PostgreSQL) на порту 5432.

Или

1.1. Если по результатам проверки видим, что не запущен процесс, то необходимо его запустить.

1.2. Если по результатам проверки видим, что процесс запущен, но слушает только «себя» 127.0.0.1.

То выполним ряд настроек.

Отредактируем конфигурационный файл

Укажем там настройку:

1.3. Если видим, что процесс запущен

То переходим к следующем пункту.

2. Проверим доступность процесса по порту, который он «слушает».

С сервера 1С выполним команду(в нашем случае имя сервера СУБД «1s-on-pg-1»):

Если доступ отсутствует – то мы увидим нечто подобное:

К причинам отсутствия доступа по данному порту можно отнести:

• Блокировка брадмауэром или другими подобными программами;
• Отсутствие доступа на уровне сети.

2.1. Проверим статус файерволла.

Если файерволл работает и блокирует порт 5432, то.

Отключим firewall:

и отключим автозапуск.

Результат должен быть следующим:

или

настроим, открыв порт 5432.

«Породить новый процесс для соединения не удалось: Ресурс временно недоступен» или «ВАЖНО: извините, уже слишком много клиентов»

Пример полного текста ошибки:

или

Описание:

В процессе работы выдается ошибка

Решение:

Изменим настройку в файле postgresql.conf

Данное число, должно быть примерно в 1.5 раза больше максимального количества пользователей.

Установим ее:

1. 1. Перейдем в терминал psql.

1. 1. Через psql установим следующие параметры командой ALTER SYSTEM SET:

FATAL: database «base» does not exist

Пример полного текста ошибки:

Описание:

При запуске базы данных выдается ошибка, которая говорит о том, что данная база не существует.

Решение:

Проверим наименование базы данных и информационной базы. Сделать это можно в консоли администрирования 1С в свойствах базы.

Учтём, что Linux чувствителен к регистру(Base/base/BASE – для него это разные имена баз).

Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Общая информация

Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:

Сервер 1С Предприятия. Часть 1 — Общие вопросы.

В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:

В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУБД. Никаких запросов от клиента к серверу управления базами данных не происходит.

Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:

host    all    all       192.168.31.0/24    ident

и приведите ее к виду:

host    all    all       192.168.31.0/24    md5

где 192.168.31.0/24 — диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.

Сервер баз данных не обнаружен
could not translate host name «NAME» to address: Temporary failure in name resolution

На первый взгляд ошибка понятна: клиент не может разрешить имя сервера СУБД, типичная ошибка для небольших сетей, где отсутствует локальный DNS-сервер. В качестве решения добавляют запись в файл hosts на клиенте, что не дает никакого результата…

А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл /etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows.

Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.

Ошибка при выполнении операции с информационной базой
server_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.

Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows запись вида: 

192.168.31.83 SRV-1C-1204

где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.

Ошибка СУБД: DATABASE не пригоден для использования

Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU. 

Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.

Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.

Ошибка СУБД: 
ERROR: could not load library «/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so»

Довольно специфичная ошибка, характерная для сборок 9.1.x и 9.2.x Postgre@Etersoft, также может приводить предыдущей ошибке. Причина кроется в неисправленной ошибке в библиотеке fasttrun.so. Решение — откатиться на сборку 9.0.x Postgre@Etersoft.

Ошибка СУБД
ERROR: type «mvarchar» does not exist at character 31

Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия

или через средство запуска 1С.

Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (по паролю)

Очень простая ошибка. Неправильно указан пароль суперпользователя СУБД postgres. Вариантов решения два: вспомнить пароль или изменить его. Во втором случае вам нужно будет изменить пароль в свойствах всех существующих информационных баз через оснастку Администрирование серверов 1С Предприятия.

Сервер баз данных не обнаружен
FATAL: database «NAME» does not exist

Еще одна очень простая ошибка. Смысл ее сводится к тому, что указанная БД не существует. Чаще всего возникает из-за ошибки в указании имени базы. Следует помнить, что информационная база 1С в кластере и база данных СУБД — две разные сущности и могут иметь различные имена. Также следует помнить, что Linux системы чувствительны к регистру и для них unf83 и UNF83 два разных имени. 

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

bumka

12.03.18 — 17:25

ansh15

1 — 13.03.18 — 13:25

rs_trade

2 — 13.03.18 — 13:57

work_mem сколько?

bumka

3 — 13.03.18 — 14:18

bumka

4 — 13.03.18 — 14:20

Обычно загрузка процессора и памяти не больше 50%, а в моменты старта автовакуума не замечала, какие показатели.

Фрэнки

5 — 13.03.18 — 14:22

(4) КА 1.1 — это только в этой базе ошибка или в разных других тоже бывает?

bumka

6 — 13.03.18 — 14:34

одновременно рядом были открыты две базы: маленькая самописная и КА. КА вылетела, а маленькая нет.

rs_trade

7 — 13.03.18 — 14:36

ИТ директор

8 — 13.03.18 — 14:38

bumka

9 — 13.03.18 — 14:40

(8) просто установить поверх?

ice777

10 — 13.03.18 — 14:40

(0) Сеть смотри. И домен, или АД как там у вас.

ice777

11 — 13.03.18 — 14:41

(10) + dhcp, если именами пользуешься

bumka

12 — 13.03.18 — 14:42

(10) Нет домена

bumka

13 — 13.03.18 — 14:43

(11) можно подробнее, пожалуйста?

ИТ директор

14 — 13.03.18 — 14:45

ИТ директор

15 — 13.03.18 — 14:46

+(14) под виндой очень много глюков в работе постгреса связано с антивирусом

bumka

16 — 13.03.18 — 14:49

(14) спасибо, проверю все

ice777

17 — 13.03.18 — 14:51

(13) если обращение к компу идет по имени- то это работа dhcp — службы имен. Если обращаться по ip- гемору намного меньше.

ice777

18 — 13.03.18 — 14:53

А еще, постри не заточен изначально на винду, это линуксовое порождение. Поэтому его часто поднимают на отдельной машине. ну и сервер 1С там же. все, больше туда совать ничего не надо.

bumka

19 — 13.03.18 — 14:54

(17) при установке PostgreSQL указывали localhost, при создании баз 1С имя компьютера.

ice777

20 — 13.03.18 — 14:57

bumka

21 — 13.03.18 — 14:58

(20) хорошо

rphosts

22 — 13.03.18 — 15:01

чё там с maxconnection?

rphosts

23 — 13.03.18 — 15:01

и да, сколько при этом реально сеансов?

bumka

24 — 13.03.18 — 15:08

maxconnection = 100

bumka

25 — 13.03.18 — 15:25

(23) 12

rs_trade

26 — 13.03.18 — 15:43

(24)(25) это разные сеансы. maxconnection можно уменьшить до 10, но это так себе оптимизация.

bumka

27 — 13.03.18 — 16:00

Нагуглила:» Но чтобы autovacuum еще и плодотворно трудился и не сильно нагружал систему, количество worker-ов должно быть как минимум  4, а в идеале – 25% всех ядер, которые выделены серверу базы данных для работы с PostgreSQL.» Что это означает? У меня в логах ругается на worker.

arsik

28 — 13.03.18 — 16:44

(27) Исходя из названия — рабочих процессов

rs_trade

29 — 13.03.18 — 17:02

bumka

30 — 14.03.18 — 16:27

Cyberhawk

31 — 14.03.18 — 16:57

Исключение антивируса и не поможет, надо его удалить

bumka

32 — 15.03.18 — 15:35

(29) ворк мем = 50. Вылетаем

arsik

33 — 15.03.18 — 15:45

(32) Так что с антивирем?

Cyberhawk

34 — 15.03.18 — 15:48

(33) Думаю, наверное, что раз отключили, то исключили его влияние, бгг

Cyberhawk

35 — 15.03.18 — 15:48

*думают

rs_trade

36 — 15.03.18 — 16:05

(32) в логах ниче нового? уровень логирования может повысить.

ansh15

37 — 16.03.18 — 10:58

(3) Оставьте только сервер приложений 1С и СУБД. Или заведите отдельный компьютер для РДП, если без него совсем никак. Про антивирус уже писали.

bumka

38 — 16.03.18 — 11:17

(36) ставила debug2, ничего нового не появилось. Ставила log_temp_files = 0, временные файлы логируются, читала, что надо увеличить тогда werk_mem?

bumka

39 — 16.03.18 — 11:19

bumka

40 — 16.03.18 — 11:20

(33) остановлю антивиря, посмотрю, что будет.

arsik

41 — 16.03.18 — 11:26

(40) Тебе же уже объяснили, что его не остановить нужно а снести

bumka

42 — 16.03.18 — 11:29

(41) слушаюсь

rs_trade

43 — 16.03.18 — 11:38

(38) почитай про ворк мем в документации. не надо ее сильно увеличивать если не олап хранилище.

Неделю без вылетов. Вероятно, полечило увеличение shared_buffers

Как заставить Сервер 1С (что работает на Windows), увидеть в сети сервер PostgreSQL на Linux UBUNTU?

Конечно, данная тема также подымается и на курсе: Администратор 1С!

Собственно решить такие проблемы как:

• «Ошибка создания информационной базы»
• «Ошибка операции администрирования»
• «Сервер баз данных не обнаружен»
• «Could not connect to server: Connection refused (Ox..00000/0000…)
• Is the server running on host 192.168….x… and accepting TCP/IP connections on port 5432?»

При установке на один физический сервер, «Cервера 1С» (кластер серверов) + СУБД PostgreSQL  проблем обычно не возникает. И «Сервер 1С» прекрасно видит PostgreSQL, новые информационные базы создаются, и все работает по умолчанию, конечно если поставили птичку во время установки СУБД на Windows — «Разрешать подключения с любых IP адресов».

Но совсем другая история, когда PostgreSQL у нас работает на Linux!

Ведь в процессе установки PostgreSQL на Linux подобных «птичек» нет )

Как решить проблему?

На самом деле все довольно просто!

Проверим в начале c какого IP принимаются подключения, и какой порт слушает сервис PostgreSQL.

Тут нам поможет команда:

На картинке ниже, мы четко видим, что наш PostgreSQL слушает только localhost — 127.0.0.1 и порт по умолчанию 5432.

Выражаясь простым языком, «Сервер 1С» может работать в паре с СУБД, только на этом севере (хосте), при текущих настройках (По умолчанию, после установки «Постгреса» на этот сервер).

И так, теперь разобравшись, что проблема действительно есть в настройках PostgreSQL, можно приступить к ее решению! 

Сперва нам нужно найти конфигурационный файл postgresql.conf

Местоположение этого файла зависит от версии СУБД PostgreSQL (На примере использую сборку от компании Postgres Professional — PostgreSQL 10.5, сборку установил на UBUNTU server 18.04 LTS).

Найти файл очень просто, используем команду:

Нас интересует все что мы видим после -D  /var/lib/pgpro/1c-10/data/

Здесь в каталоге /data/ и лежит наш файл postgresql.conf

Идем в этот каталог, откроем для редактирования postgresql.conf, и внесем нужные правки.

Для передвижения по каталогам и редактированию файлов на UBUNTU server 18.04, я использую MC (Midnight Commander).

Как его установить, писал здесь >>

(Выбрав файл postgresql.conf) далее давим клавишу F4:

Ищем строку #listen_addresses = ‘localhost’.

Раскомментируем строку (убрав #).

И приведем строку к виду: listen_addresses = ‘*’

Давим F2 + Enter и сохраняем файл.

Далее выполним перезапуск сервиса postgresql:

Стоп:

service postgrespro-1c-10 stop

И старт:

service postgrespro-1c-10 start

(Команда перезапуска у Вас будет отличатся, если версия PostgreSQL другая или другой сборки).

Затем стоит проверить работает ли PostgreSQL:

service postgrespro-1c-10 status

И если видим (как на картинке ниже) зеленым цветом active (running) значит PostgreSQL работает!

Смотрим, что теперь «слушает» PostgreSQL:

Отлично!

После перезапуска сервиса, PostgreSQL принимает подключения действительно с любых IP адресов на стандартный порт 5432!

Но!  не спешите сейчас бежать на Сервер 1С, создавать новую информационную базу, или выполнять подключение.

Сервер 1С встретит Вас новой ошибкой! )

«ВАЖНО: в pg_hba.conf нет записи для компьютера «192.168.128.13», пользователя «postgres», базы «template1″, SSl выкл.»

Сервер 1С требует от нас создать еще одну запись, уже в другом файле pg_hba.conf

«Надо, так надо )»

Открываем для редактирования файл pg_hba.conf, он к слову находится в том же каталоге, что и файл postgresql.conf

Ищем строку: host      all          all                  127.0.0.1/32      md5

И приводим к виду: host      all          all                  192.168.128.13/24      md5

Где 192.168.128.13 ip адрес нашего Сервера 1С. (Тот сервер, где работает Сервер 1С).

Кстати! можно поступить и по-другому.

Просто добавить в строке ниже еще одну запись (Ту которую от нас и требует Сервер 1С):

Вот и все!

Сохраним файл и выполним перезапуск PostgreSQL.

Теперь новая информационная база 1С, будет создана успешно!

Сервер 1С работает на Windows, а PostgreSQL на Linux!

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Ошибки СУБД. 1С+PostgreSQL+Linux. Часть 2.

Ошибка СУБД:

Продолжение сообщения может быть различным:

DATABASE не пригоден для использования

Пример полного текста ошибки:

Описание ошибки:

База не запускается после установки и создания.

Решения:

Установим версию предназначенную для работы с 1С:Предприятием. Скачать такую можно с сайта 1С (при наличии купленного ИТС и открытого доступа), или приобрести у PostgresPro.

Либо проверим все ли зависимости были установлены. И установим недостающие.

ERROR: type «tt7» already exists

Пример полного текста ошибки:

Описание:

Данная ошибка является «плавающей» и может возникать в различных местах

Решение:

Выгрузим и загрузим базу данных средствами 1С:Предприятия(через файл *.dt).

ERROR: could not read block

Описание ошибки:

База не запускается. Разрушились диски.

Решения:

Переносим базу на другую дисковую систему.

Разворачиваем из резервной копии.

Не удалось запустить сервер PostgreSQL

Пример полного текста ошибки:

Описание:

Такая ситуация часто случается у начинающих администраторов в случае, если они хотят инициализировать сервер в каталог отличный от каталога по умолчанию. При этом сервер уже запустили из каталога по умолчанию.

В этой ситуации при попытке запуска видно ошибку – сервер не запускается.

А при проверке состояния видно, что сервер работает.

Если проверим запущенные процессы пользователя postgres, то можно увидеть, что порт 5432 занят кластером PostgreSQL, только запущенным из каталога по умолчанию.

Решение:

Остановим работающий кластер сервера СУБД.

Инициализируем кластер из нового каталога(если он не инициализирован).

Запустим из нового каталога.

Длительный запуск 1С:Предприятия при работе с СУБД PostgreSQL

Описание:

Длительный запуск, длительный захват объектов в хранилище, длительное сохранение конфигурации 1С:Предприятия.

Решение:

Такая проблема может быть связано с настройками СУБД PostgreSQL.

Рассчитаем настройки СУБД.

Описание настроек приведено на ИТС.

Выполним настройки, для этого перейдем в терминал psql:

Через psql установим параметры командой ALTER SYSTEM SET(параметры необходимо указать для вашей СУБД):

Из файла *xlsx загружаются в 1С иероглифы/ в файл выгружаются иероглифы.

Описание ошибки:

При загрузке данных из файла *.xlsx в 1С отображаются иероглифы. Используемая СУБД PostgreSQL/PostgresPro.

Также возможна проблема с кодировкой в выгружаемом файле из 1С:

Решение:

На сервере СУБД проверим и выполним настройку локали.

1. Проверим наличие локали:

2. Проверим переменную:

Корректное значение результатов выполнения команд 2, 3:

3. Если результат не соответствует, выполним:

5. Выполним перезапуск серверов СУБД

Еще можно посмотреть

Ошибка «Слишком много открытых файлов» или«Too many open files» В 1С на Linux

Устраняем ошибку «Слишком много открытых файлов» или «Too many open files» в 1С под ОС Linux (Red Hat 7/Centos 7) 1. Увеличиваем лимит на открытые файлы всей системы. 2. Увеличиваем лимит на открытые файлы для процессов 1С. 3. Увеличиваем лимиты на открытые файлы для процесса 1С редактированием файла демона. 4. Увеличиваем максимальное число сегментов разделяемой […]

Публикация 1С на Веб сервере Apache Linux

Пошаговые инструкции по публикация базы и web-сервисов 1С на веб-сервере Apache 2.4 на Linux.

Отладка на сервере 1С на Linux

Настройка отладки на Linux сервере 1С. Пошаговый процесс настройки tcp и http отладки.

Ошибки публикации базы и веб сервиса на веб сервере 1C+ Apache +Linux.

Многие из нас привыкли публиковать базу или веб сервис 1С нажатием нескольких кнопок. Но не все из многих знают, что для этого необходимо запустить(от имени администратора!) конфигуратор 1С:Предприятие именно на той машине, где установлен веб сервер(а именно компонента веб-расширения 1С:Предприятия). В случае, если веб-сервер и компонента веб-расширения 1С:Предприятия установлены на машину с ОС Linux без […]

Проверка рабочих процессов сервера 1С на Linux

Как проверить на Linux запущены ли процессы сервера 1С. Проверка открытых портов сервера 1С

Большинство современных конфигураций позволяет осуществлять хранение прикрепленных файлов не только в базе, но и на файловом сервере. Последний вариант хорош тем, что помогает предотвратить неоправданно быстрый рост базы данных из-за прикладываемых пользователями файлов. В этой статье мы ответим на следующие вопросы: 1. Как сделать Network File System (NFS) — шару на linux? 2. Как настроить […]

Ошибки сервера 1С на Linux

Описание типичных ошибок которые возникают при запуске службы сервера 1С на Linux и пути их исправления

Источник

1c предприятие 8.2 – Troubleshooting

Последнее время отвечая на комментарии в теме “Установка сервера 1с предприятия” замечаю что 90% ошибок повторяются из раза в раз, причем ошибки в основном связаны либо с невнимательностью, либо с установкой на платформу отличную от указанной в статье. Этот раздел посвящен именно ошибкам которые возникают во время установки и настройки сервера 1с предприятия и его компонентов.

В качестве эпиграфа приведу один из комментариев к статье “Установка сервера 1с предприятия на Fedora 12.”

1. Ошибка при запуске config_server

Проблема возникает на операционных системах с архитектурой x86_64 из-за отсутствия 32-х битного пакета glibc.

2. Не запустился сервер 1с предприятия

После завершения установки сервер 1с предприятия сообщил о том что запустился, но не работает:

При попытке остановить пишет:

1. Проверяем какие порты слушает сервер 1с предприятия

Если в результате проверки получилось что работает только rmngr (менеджер сервера), значит при установке были не правильно созданы конфигурационные файлы и мы можем переходить к п.2.

2. Проверяем selinux

Сервер 1с предприятия вполне может работать при включенным SELinux c политикой targeted в запрещающем режиме Enforcing, однако в некоторых комбинациях он может вызвать проблему при запуске ragent (агента сервера 1с). Проверяем:

Открываем для редактирования /etc/sysconfig/selinux и меняем параметр SELINUX на disabled или permissive.

3. Разрешение имен hostname и hosts

Для работы сервера 1с предприятия очень важно что бы его имя правильно преобразовывалось в IP. По хорошему мы должны иметь возможность с любого хоста в сети разрешить FQDN и краткое имя сервера, но просто для запуска нам достаточно, что бы имя хоста разрешалось в пределах только самого сервера.

Смотрим какой у нас hostname, если hostname получился похожим на localhost.localdomain обязательно меняем его в файле /etc/sysconfig/network на FQDN-имя сервера, после перезагружаем систему.

Просматриваем содержимое файла /etc/hosts, если видим что-то похожее – можно сразу начинать править.

Для сервера с именем 1csrv.mydomain.local файл hosts должен выглядеть следующим побразом.

При этом 192.168.20.164 – адрес нашего сервера.

4. Пересоздаем конфигурацию по умолчанию

Если сервер 1с предприятия при запуске не находит свои конфигурационные файлы srvribrg.lst и 1CV8Reg.lst – он создает их заново. Этим мы и воспользуемся, чтобы сгладить проблемы возникшие при установке. Останавливаем сервер 1с предприятия:

Удаляем конфигурационные файлы:

Если мы видим вывод подобный приведенному выше, значит все отлично сервер 1с предприятия запустился и работает.

3. Не могу подключиться к серверу 1с предприятия.

При попытке соединиться с сервером через консоль “Администрирование серверов 1с-предприятия” появляется “Ошибка соединения с сервером 1с предприятия 8.2: server_addr=tcp//1csrv.mydomain.local descr=Ошибка сетевого доступа к серверу”.

1. Проверяем сетевое соединение с сервером. С компьютера где установлена консоль управления запускаем “ping 1csrv.mydomain.local”, если пинги ходят значит переходим к следующему пункту.

2. Проверяем работает ли сервер 1с предприятия. Для этого на сервере выполняем следующую комманду:

Если мы получили другой результат – значит сервер 1с предприятия не работает или работает не правильно и нам нужно обратиться к 2-ой части этого манула “Не запустился сервер 1с предприятия”.

3. Настройка Iptables. Сервер 1с предприятия в большинстве случаев находится в пределах локальной сети и его вполне можно использовать с отключенным файрволом без большой угрозы безопасности. Отключаем iptables:

Для тех кто все-таки хочет заморочиться с правильной настройкой.

Консоли администрирования нужен доступ к агенту сервера (ragent) по порту 1540, а для создания базы понадобится еще и доступ к рабочим процессам по портам 1562-1591. Толстому клиенту нужен доступ к менеджеру сервера (rmngr) по порту 1541 и рабочим процессам порты 1562-1591.

Остальное зависит только от вашей фантазии. Для стандартно настроенного файрвола в CentOS набор разрешающих правили будет выглядеть приближенно так:

4. Postgesql – DATABASE не пригоден для использования

При создании базы данных через консоль администрирования, появляется сначала ошибка mvchar или fasttrun, а затем окно с ошибкой “DATABASE не пригоден для использования”.

1. Проверяем установлен ли potgresql-contrib. Для этого запрашиваем список установленных пакетов PostgreSQL:

Если в списке не нет postgresql-contrib – устанавливаем его из установочной директории и перезапускаем PostgreSQL:

2. Проверяем пакеты libicu. Не редко PostgreSQL собирают на одной машине, а устанавливают потом на другую – жесткой зависимости от пакетов licicu нет, отсюда и ошибки. Запрашиваем список пакетов icu:

Если не находим в выводе icu и libicu, устанавливаем их.

3. Ссылки на libicu. Наверное самый наболевший в этой теме вопрос, операционных систем много, версий библиотек еще больше – и ссылки для каждого случая свои. Смотрим где лежат библиотеки, установленные в пакете libicu:

Делаем соответствующие ссылки

4. Удаление базы. Итак мы проделали все вышеперечисленные процедуры, но ошибка “DATABASE не пригоден для использования” все-равно появляется. Это связано с тем что базу мы уже создали использования пакетов contrib и libicu, и 1с не может с ней работать. Запрашиваем список баз и удаляем испорченную.

Заключение.

Этот раздел создан что бы упростить жизнь тем кто сталкивается с проблемами при установке 1с предприятие под Linux. Если вы хотите дополнить или к примеру вашей неполадки не оказалось в статье пишите на форум в теме “Настройка 1с предприятия 8.2 под Linux”.

Нет комментариев : “1c предприятие 8.2 – Troubleshooting”

Трекбеки/Пинги

Свежие комментарии

Рубрики

Разработано на CMS WordPress | ДизайнElegant Themes

Источник

Установка сервера 1С:Предприятия и PostgreSQL на платформе Linux.

Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.

Общая информация

Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:

В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:

В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУДБ. Никаких запросов от клиента к серверу управления базами данных не происходит.

Сервер баз данных не обнаруженВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:

host all all 192.168.31.0/24 ident[/pre]

и приведите ее к виду:

host all all 192.168.31.0/24 md5[/pre]

Сервер баз данных не обнаруженcould not translate host name «NAME» to address: Temporary failure in name resolution

На первый взгляд ошибка понятна: клиент не может разрешить имя сервера СУБД, типичная ошибка для небольших сетей, где отсутствует локальный DNS-сервер. В качестве решения добавляют запись в файлhosts на клиенте, что не дает никакого результата.

А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл/etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows.

Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.

Ошибка при выполнении операции с информационной базойserver_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.

Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows запись вида:

где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.

Ошибка СУБД: DATABASE не пригоден для использования

Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU.

Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.

Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.

Ошибка СУБД: ERROR: could not load library «/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so»

Ошибка СУБДERROR: type «mvarchar» does not exist at character 31

Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия

или через средство запуска 1С.

Сервер баз данных не обнаруженВАЖНО: пользователь «postgres» не прошёл проверку подлинности (по паролю)

Очень простая ошибка. Неправильно указан пароль суперпользователя СУБД postgres. Вариантов решения два: вспомнить пароль или изменить его. Во втором случае вам нужно будет изменить пароль в свойствах всех существующих информационных баз через оснастку Администрирование серверов 1С Предприятия.

Сервер баз данных не обнаруженFATAL: database «NAME» does not exist

Источник

Ошибки СУБД. 1С+PostgreSQL+Linux. Часть 1.

Ошибка 1С «Сервер баз данных не обнаружен»

При работе с 1С в клиент-серверном варианте могут возникать ошибки, которые напрямую не связаны с 1С:Предприятием, а связаны непосредственно с сервером управления баз данных.

Одна из распространенных ошибок — «Сервер баз данных не обнаружен…».

Продолжение данного сообщения может быть различным:

Далее рассмотрим подробнее каждую ошибку.

Could not translate host name «NAME» to address: Temporary failure in name resolution

Пример полного текста ошибки:

Описание:

Ошибка может возникать как при создании базы, так и при запуске информационной базы.

Решение:

Настроим DNS-адресацию или пропишем адреса в файл hosts. Обратите внимание, что в данном случае проблема в том, что на сервере 1С нет информации о доменном имени сервера СУБД PostgreSQL. Подробнее о DNS — Настройка DNS-адресации для 1С сервера.

ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Пример полного текста ошибки:

Описание: Ошибка возникает при создании базы.

Решение:

Настроим проверку подлинности.

Файл должен содержать только следующие строки (содержащие ip серверов 1С) (остальные удалим или пометим как комментарий):

Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.

Последняя колонка указывает на метод авторизации.

Если пока теряетесь в настройках доступа. Для понимания, можно сначала открыть все, запустить сервер.

А после удачного старта сервера СУБД разбираться с настройками доступа.

ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»

Пример полного текста ошибки:

Описание ошибки:

Ошибка связана с отсутствием прописанного доступа к базе данных в файле pg_hba.conf

Решение:

Добавим запись в файл pg_hba.conf.

Приведем пример содержания файла, который открывает доступ:

Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.

Is the server running on host and accepting TCP/IP connections on port 5432?

Пример полного текста ошибки:

Описание:

Проблема может возникать как при создании информационной базы из консоли администрирования 1С: Предприятия, так и при ее запуске в процессе эксплуатации уже существующей базы данных.

Решение:

В данном случае необходимо понимать, что рабочего процесса:

Либо нет;

Либо клиент(в нашем случае сервер 1С) его не «видит» по ряду причин:

— Отсутствие доступа;

— Обращение по другому адресу.

1. Первоначально, конечно, проверим, есть ли на сервере СУБД PostgreSQL в запущенных процессах процесс postmaster/postgres (в зависимости от версии PostgreSQL) на порту 5432.

Источник

Ошибка при создании базы на сервере 1с 8.3+postgresql Debian 7

Всем привет форумчане!

В общем я настроил сервер на базе debian 7 там установил сервер 1с 8.3 и базу данных postgresql, все работает! На своем компе в сети я установить оснастку адмиинстрирования сервера 1с, там же добавил центральный сервер,все хорошо, но при создании базы вылетает вот такая ошибка, может кто знает в чем проблема весь инет перерыл не нашел подобной ошибки!Скрин внутри https://yadi.sk/d/jhL1c5GRkPzYY

Надо читать первую ошибку. Возможно вторая исходит из первой. Убедитесь, что рабочие процессы созданы в этой оснастке?

дык это первая ошибка, рабочие процессы есть вот https://yadi.sk/d/BB1cLsIKkQ2Fm

а /home/ случаем не по nfs примонтирован?

нет, я ничего не монтировал после установки системы

1) в файле hosts на винде добавили запись на ваш линуксовый сервер? 2) фаер на винде допускает соединение с линуксовым сервером?

да в фале hosts все прописал, касперского отключал фаер не работает! такая же ерунда

а версия postgre какая? У меня нормально заработало только с вот этой-

у меня такая же стоит PostgreSQL 9.2.1-eter8debian on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 64-bit

Система Linux postgres 2.6.32-19-pve #1 SMP Wed May 15 07:32:52 CEST 2013 x86_64 GNU/Linux

Интересно что при создании базы через сервер 1с установленный на виндовс, все нормально база поднимается!

Попробовал, у меня из линуксового толстого клиента 1С тоже не получается базу создать (сервер предприятия и постгре на лине). С винды всё добаляется. у 1с вроде бы даже баг на эту тему проскакивал, видимо не пофиксили.

Так и живем, надо базу создать, бегаю к компъютеру с win 🙁

Значит сервер 1с на линуксе не будет работать, можно и не мучиться?

да почему не будет, он работает, просто не надо дебианом пользоваться, а ставить red hat и его производные, качать постргре с сайта 1С и радоваться жизни

да в принципе у меня такие же потребности, небольшое количество подключений, только я так и не пойму как ты базы то создаешь на сервере 1с который у тебя на debiane? Т.е. у тебя сервер 1с стоит на виндовой машине? так?:)

У меня сейчас стоит сервер 1с на виндовой машине дык я могу создать базу на сервере с postgresql и она будет работать нормально!

Внимание! Это уничтожит всю информацию о существующем кластере. ЕСЛИ ЭТО ЕЩЕ НЕ В ПРОДАКШЕНЕ, может попробовать

Источник

22.09.21 — 16:58

Если создать средствами 1с base/xxxxxx is missing

1 — 22.09.21 — 17:05

Какого пользователя постгре указываешь?

2 — 22.09.21 — 17:25

postgres как бы он всегда был

3 — 22.09.21 — 18:00

ху из «base/xxxxxx» ?

4 — 22.09.21 — 18:01

(3) откуда «/» и что слева и справа?

5 — 22.09.21 — 18:40

6 — 22.09.21 — 18:47

Открываю постгри база созданная с крестом

7 — 23.09.21 — 09:27

а там уже есть базы или это первая?

8 — 23.09.21 — 10:07

базы есть, 4 штуки. создавались без проблем

9 — 23.09.21 — 10:47

(8) так же 1синой? или через pgadmin? или скриптом?

10 — 23.09.21 — 12:24

так же 1синой

11 — 25.09.21 — 12:53

апну

12 — 25.09.21 — 14:03

пока докопался что ping localhost должен в ответ 127.0.0.1, у меня 0:0:1:0

хотя изначально ipv6 отключался

13 — 25.09.21 — 18:21

В тж что написано, что написано в логах постгреса?

14 — 25.09.21 — 18:30

(12) Значит, так отключал.

15 — 25.09.21 — 19:50

16 — 26.09.21 — 10:03

Предварительно создать пустую базу в постгри не пробовал?

17 — 26.09.21 — 10:54

18 — 26.09.21 — 10:57

(16)DATABASE не пригоден для использования

19 — 26.09.21 — 11:19

PostgreSQL 11.7-7.1C(x64)

Платформа 8.3.19.1150 может из-за платформы

20 — 27.09.21 — 11:11

подниму

21 — 27.09.21 — 11:13

The database subdirectory «base/60864287» is missing.

22 — 27.09.21 — 11:15

в pg_hba.conf нет настройки на ваш хост судя по

no pg_hba.conf entry for host «fe80::85ab:7da2:5d03:83cd%5», user «postgres», database «template1», SSL off

23 — 27.09.21 — 11:55

24 — 27.09.21 — 13:14

psql -l показывает твою базу?

25 — 27.09.21 — 13:56

BuhAstra_30 | postgres | UTF8     | Russian_Russia.1251 | Russian_Russia.1251 |

Roznica     | postgres | UTF8     | Russian_Russia.1251 | Russian_Russia.1251 |

Stroytorg   | postgres | UTF8     | Russian_Russia.1251 | Russian_Russia.1251 |

postgres    | postgres | UTF8     | Russian_Russia.1251 | Russian_Russia.1251 |

template0   | postgres | UTF8     | Russian_Russia.1251 | Russian_Russia.1251 | =c/postgres          +

             |          |          |                     |                     | postgres=CTc/postgres

template1   | postgres | UTF8     | Russian_Russia.1251 | Russian_Russia.1251 | =c/postgres          +

             |          |          |                     |                     | postgres=CTc/postgres

test3       | postgres | UTF8     | Russian_Russia.1251 | Russian_Russia.1251 |

26 — 27.09.21 — 13:56

test3 создавал через 1с

27 — 27.09.21 — 14:22

28 — 27.09.21 — 14:42

echo $PGDATA ?

29 — 27.09.21 — 15:00

30 — 27.09.21 — 15:09

По хорошему, выгрузить работающие базы и создать кластер заново.

Заодно обновить СУБД до 12.7(для 8.3.19) и саму платформу до последней версии.

И поменять сервер. Ну, это по вкусу.

31 — 27.09.21 — 15:47

(29) я так понимаю копии лучше сделать)

опыта на постгри нет

(31) Разумеется. Остановить службу СУБД и скопировать весь каталог data в надежное место. Рабочие базы дополнительно pg_dump-ом, их же(на всякий случай) в dt, при отсутствии пользователей и выключенных регламентных заданиях.

Потом все эксперименты.

Столкнулся с неприятной ошибкой во время работы с сервером администрирования 1С в связке с PostgreSQL. Сразу скажу, что данная связка сулит много нюансов и подводных камней, так что без крайней необходимости не рекомендую с ней связываться, если нет хорошего опыта работы с postgresql. Либо придется учиться по ходу дела.

Суть проблемы вот в чем. Я установил postgresql 10 от postgresqlpro примерно по той же схеме, что описана у меня в статье про установку и настройку postgresql для работы с 1с. После установки выполнил инициализацию кластера простой командой:

# pg-setup initdb

Затем из дампа залил базу и какое-то время все это без проблем работало. Потом стало нужно создать новую базу. Я создал через консоль postgresql базу:

$ create database panda with owner = usr1cv8 ENCODING = 'UTF8' LC_COLLATE = 'ru_RU.UTF-8' LC_CTYPE = 'ru_RU.UTF-8';

И пошел создавать базу через панель администрирования 1с. У меня этого не получилось, вылезла ошибка.

Ошибка при создании информационной базы:
Ошибка операции администрирования
Ошибка СУБД: 
ERROR: type "mvarchar" does not exist 
LINE 1: create table Config (FileName mvarchar(128) not null, Creati...^

Начал искать информацию на эту тему. Понял, что создавать базу из консоли нельзя, необходимо это делать через панель администрирования 1С. ОК, удалил базу через консоль:

$ drop database panda;

Пошел в панель администрирования, но создать базу не получилось. К сожалению, не заскринил ошибку. Но суть в том, что база создавалась не в той кодировке. Сейчас поясню. Смотрим список баз на сервере:

root@sql:/opt/pgpro/1c-10/bin# ./psql -U postgres -l
                                   Список баз данных
    Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
------------+----------+-----------+-------------+-------------+-----------------------
 enterprise | usr1cv8  | UTF8      | ru_RU.utf8  | ru_RU.utf8  | =Tc/usr1cv8          +
            |          |           |             |             | usr1cv8=CTc/usr1cv8
 panda      | usr1cv8  | UTF8      | en_US.UTF-8 | en_US.UTF-8 | 
 postgres   | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | 
 template0  | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
            |          |           |             |             | postgres=CTc/postgres
 template1  | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
            |          |           |             |             | postgres=CTc/postgres

База enterprise была залита из дампа и имеет правильную кодировку. Базу panda создает 1С через консоль администрирования, и у нее кодировка LC_COLLATE и LC_CTYPE en_US.UTF-8, а должна быть ru_RU.UTF-8. Это при том, что консоль сервера в момент настройки postgresql была правильная.

# locale
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

Я думал, что пропатченой сборки postgresql и нужной консоли достаточно, чтобы все было в порядке с кодировкой. Но ошибся. Раньше не припоминаю, чтобы сталкивался с подобной ошибкой. Получается, я попал в тупик. Я могу руками создать базу данных с нужными кодировками, но она не будет работать, так как 1С должна базу создать сама. Если же я создаю базу через 1С, выбираются дефолтные шаблоны с неподходящей кодировкой и ничего не работает.

Я нашел один вариант решения — проинициализировать заново кластер, явно указав кодировки:

# initdb --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF-8 --lc-ctype=ru_RU.UTF-8 --encoding=UTF8

Как я понял, все текущие базы дропнутся. Возможно понял не правильно, но проверять не захотелось, так как текущая база там на 80 гигов и заливать дамп очень долго. Нашел другой способ — замена шаблона. Вот последовательность действий в консоли postgresql для удаления текущего шаблона и создания нового с нужными кодировками.

$ update pg_database set datistemplate = false where datname='template1';
$ drop database template1;
$ create database template1 ENCODING = 'UTF8' LC_COLLATE = 'ru_RU.UTF-8' LC_CTYPE = 'ru_RU.UTF-8' template=template0;
$ update pg_database set datistemplate = true where datname='template1';

После этого получилось через консоль 1С создать базу и начать с ней работать. Список баз стал выглядеть вот так:

root@sql:/opt/pgpro/1c-10/bin# ./psql -U postgres -l
                                   Список баз данных
    Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
------------+----------+-----------+-------------+-------------+-----------------------
 enterprise | usr1cv8  | UTF8      | ru_RU.utf8  | ru_RU.utf8  | =Tc/usr1cv8          +
            |          |           |             |             | usr1cv8=CTc/usr1cv8
 panda      | usr1cv8  | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | 
 postgres   | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | 
 template0  | postgres | UTF8      | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
            |          |           |             |             | postgres=CTc/postgres
 template1  | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | 

Ошибок больше не было.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.