1с ошибка при выполнении файловой операции too many open files

Устраняем ошибку «Слишком много открытых файлов» или «Too many open files» в 1С под ОС Linux (Red Hat 7/Centos 7)

1. Увеличиваем лимит на открытые файлы всей системы.

2. Увеличиваем лимит на открытые файлы для процессов 1С.

3. Увеличиваем лимиты на открытые файлы для процесса 1С редактированием файла демона.

4. Увеличиваем максимальное число сегментов разделяемой памяти для всей системы.

Подробнее об ошибке

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

Описание:

Данная ошибка связана с тем, что ОС Linux исчерпала ограниченный ей лимит файлов на открытие и может возникать как при работе пользователя в пользовательском режиме, так и при работе разработчика с хранилищем конфигурации.

Побочными ошибками данной проблемы могут являться также ошибки работы с дисковой подсистемой. Такие как:

Решение:

На всех серверах 1С выполним следующие настройки лимитов открываемых файлов.

Увеличиваем лимит на открытые файлы всей системы.

1. Получим значение количества файлов, которые можно открыть в нашей файловой системе:

Скорее всего, здесь мы увидим числа порядка: 97822; 65208 и т.д.

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

Данное значение используем в дальнейшей настройке.

Но, если понадобится их увеличить – добавим строку настроек в конфигурационный файл /etc/sysctl.conf любым удобным способом:

2. Перечитаем параметры:

где 6500 – это то число файлов, которое нам необходимо иметь возможность открывать в нашей файловой системе.

Увеличиваем лимит на открытые файлы для процессов 1С.

1. Отредактируем файл:

Добавим строки:

2. Перечитаем параметры:

3. Убедимся, что изменения вступили в силу. Получим pid службы:

4. По номеру pid получим значение параметра «max open files»:

Значение должно быть 65000.

Увеличиваем лимиты на открытые файлы для процесса 1С редактированием файла демона.

Результат данной настройки будет аналогичен предыдущему варианту.

1. Отредактируем настройки:

Добавим строки:

2. Обновим конфигурацию демон:

3. Перезапустим демон:

Отметим также, что помимо настроек, относящихся к количеству открытых файлов – может понадобится обратить внимание на настройки максимального числа сегментов разделяемой памяти для всей системы.

Увеличиваем максимальное число сегментов разделяемой памяти для всей системы.

1. При необходимости — установим настройку:

1. Проверим, что настройка установилась:

Все наши модифицированные настройки можем увидеть в конфигурационном файле /etc/sysctl.conf:

( 2 оценки, среднее 4.5 из 5 )

Очень часто при работе на высоконагруженных Linux серверах могут возникать ошибки “too many open files”. Это означает, что процесс открыл слишком много файлов (читай файловых дескрипторов) и не может открыть новые. В Linux ограничения “max open file limit“ установлены по умолчанию для каждого процесса и пользователя, и они не слишком высокие.

В данной статье мы рассмотрим, как проверить текущие ограничения на количество открытых файлов в Linux, как изменить этот параметр для всего сервера, для отдельных сервисов и для сеанса. Статья применима для большинства современных дистрибутивов Linux (Debian, Ubuntu, CentOS, RHEL, Oracle Linux, Rocky и т.д.)

Ошибка: Too many open files и лимиты на количество открытых файлов в Linux

Чаще всего ошибку “too many open files“. Чаще всего эта ошибка встречается на серверах с установленным веб-сервером NGINX/httpd, сервером БД (MySQL/MariaDB/PostgreSQL), при чтении большого количества логов. Например, когда веб-серверу Nginx не хватает лимита для открытия файлов, вы получите ошибку:

socket () failed (24: Too many open files) while connecting to upstream

Или:

HTTP: Accept error: accept tcp [::]:<port_number>: accept4: too many open files.

В Python:

OSError: [Errno 24] Too many open files.

Максимально количество файловых дескрипторов, которые могут быть открыты в вашей файловой системе всеми процессами можно узнать так:

# cat /proc/sys/fs/file-max

Чтобы узнать, сколько файлов открыто сейчас, выполните:

$ cat /proc/sys/fs/file-nr

7744    521      92233720

• 7744 — суммарное количество открытых файлов
• 521– число открытых файлов, но которые сейчас не используются
• 92233720– максимальное количество файлов, которое разрешено открывать

В Linux ограничение на максимальное количество открытых файлов можно натсроить на нескольких уровнях:

• Ядра ОС
• Сервиса
• Пользователя

Чтобы вывести текущее ограничение на количество открытых файлов в ядре Linux, выполните:

# sysctl fs.file-max

fs.file-max = 92233720

Выведем ограничение на количество открытых файлов для одного процесса текущего пользователя:

# ulimit -n

По умолчанию количество файлов для одного процесса этого ограничено числом 1024.

Выведем максимальное количество для одного пользователя (max user processes):

# ulimit –u

5041

Умножаем 1024 * 5041 дает нам 5161984 – это максимально количество открытых файлов всеми процессами пользователя.

В Linux есть два типа ограничений на количество открытых файлов: Hard и Soft. Soft ограничения носят рекомендательный характер, при превышении значения пользователь будет получать предупреждения. Если количество открытых файлов превысило hard лимит, пользователь не сможет открыть новые файлы пока не будет закрыты ранее открытые.

Для просмотра текущих лимитов используется команда ulimit с опцией
-S
(soft) или
-H
(hard) и параметром
-n
(the maximum number of open file descriptors).

Для вывода Soft-ограничения:

# ulimit -Sn

Для вывода Hard-ограничения:

# ulimit -Hn

Глобальные ограничения на количество открытых файлов в Linux

Чтобы разрешить всем сервисам открывать большее количество файлов, можно изменить лимиты на уровне всей ОС Linux. Чтобы новые настройки работали постоянно и не сбрасывались при перезапуске сервера или сессии, нужно поправить файл /etc/security/limits.conf. Строки с разрешениями выглядит так:

Имя_пользователя тип_огрничение название_ограничения значение

Например:

apache  hard nofile 978160
apache soft nofile 978160

Вместо имени пользователя можно указать
*
. Это означает, что это ограничение будет применяться для всех пользователей Linux:

* hard nofile 97816
* soft nofile 97816

Например, вы получили ошибку too many open files для nginx. Проверьте, сколько файлов разрешено открывать процессу этому пользователю:

$ sudo -u nginx bash -c 'ulimit -n'

1024

Для нагруженного сервера этого недостаточно. Добавьте в /etc/security/limits.conf строки

nginx hard nofile 50000
nginx soft nofile 50000

В старых ядрах Linux значение fs.file-max может быть равно 10000. Поэтому проверьте это значение и увеличьте его, чтобы оно было больше чем ограничение в limits.conf:

# sysctl -w fs.file-max=500000

fs.file-max = 500000

Проверьте, что в файле /etc/pam.d/common-session (Debian/Ubuntu или /etc/pam.d/login для CentOS/RedHat/Fedora) есть строчка:

session required pam_limits.so

Если нет, добавьте ее в конец. Она нужна, чтобы ограничения загружались при авторизации пользователя.

После изменений, перезапустите терминал и проверьте значение лимита max_open_files:

# ulimit -n


97816

Увеличить лимит открытых файловых дескрипторов для отдельного сервиса

Вы можете изменить лимит на количество открытых файловых дескрипторов для конкретного сервиса, а не для всей системы. Рассмотрим на примере apache. Чтобы изменить значения, откройте настройки службы через systemctl:

# systemctl edit httpd.service

Добавьте необходимые лимиты, например:

[Service]
LimitNOFILE=16000
LimitNOFILESoft=16000

После изменения, нужно обновить конфигурацию сервиса и перезапустить его:

# systemctl daemon-reload
# systemctl restart httpd.service

Чтобы проверить, изменились ли значения, нужно получить PID сервиса:

# systemctl status httpd.service

Например, вы определил PID сервиса 32724:

# cat /proc/32724/limits | grep "Max open files”

Значение должно быть 16000.

Так вы изменили значения Max open files для конкретного сервиса.

Увеличить количество открытых файлов для Nginx и Apache

После того, как вы увеличил ограничения на количество открытых файлов для сервера, нужно также поправить конфигурационный файл службы. Например, для веб-сервера Nginx в файле конфигурации /etc/nginx/nginx.conf нужно задать значение в директиве:

worker_rlimit_nofile 16000

Директива worker_rlimit_nofile задает ограничение на количество файлов, открытых в рабочем процессе (
RLIMIT_NOFILE
). В Nginx файловые дескрипторы нужны для возврата статического файла из кэша для каждого подключения клиента. Чем больше пользователей использует ваш сервер и чем больше статических файлов отдает nginx, тем большее количество дескрипторов используется. Сверху максимальное количество дескрипторов ограничивается на уровне ОС и/или сервиса. При превышении количеств открытых файлов nginx появится ошибка
socket() failed (24: Too many open files) while connecting to upstream
.

При настройке Nginx на высоконагруженном 8-ядерном сервере с worker_connections 8192 нужно в worker_rlimit_nofile указать 8192*2*8 (vCPU) = 131072.

После чего выполнить рестарт Nginx:

# nginx -t && service nginx -s reload

Для apache, нужно создать директорию:

# mkdir /lib/systemd/system/httpd.service.d/

После этого создайте файл limit_nofile.conf:

# nano /lib/systemd/system/httpd.service.d/limit_nofile.conf

И добавьте в него:

[Service]
LimitNOFILE=16000

Не забудьте перезапустить сервис httpd.

Лимиты file-max для текущей сессии

Чтобы изменить лимиты на открытые файлы в рамках текущей сессии пользователя, выполните команду:

# ulimit -n 3000

Если указать здесь значение большее, чем заданное в hard limit, появится ошибка:

-bash: ulimit: open files: cannot modify limit: Operation not permitted

Когда вы завершите текущую сессию терминала и откроете новую, лимиты вернутся к начальным значениям, указанным в файле /etc/security/limits.conf.

В данной статье мы разобрались, как решить проблему с недостаточным лимитом для открытых файловых дескрипторов в Linux и рассмотрели несколько вариантов изменения лимитов на сервере.

Если вы работали с программами, которым приходится обрабатывать очень большое количество файловых дескрипторов, например с распределенными базами данных, такими, как Elasticsearch, то вы, наверняка, сталкивались с ошибкой «too many open files в Linux».

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

Дословно эта ошибка означает, что программа открыла слишком много файлов и больше ей открывать нельзя. В Linux установлены жёсткие ограничения на количество открываемых файлов для каждого процесса и пользователя.

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

cat /proc/sys/fs/file-max

Посмотреть текущие ограничения количества открытых файлов для пользователя можно командой:

ulimit -n

Утилита ulimit возвращает два вида ограничений — hard и soft. Ограничение soft вы можете менять в любую сторону, пока оно не превышает hard. Ограничение hard можно менять только в меньшую сторону от имени обычного пользователя. От имени суперпользователя можно менять оба вида ограничений так, как нужно. По умолчанию отображаются soft-ограничения:

ulimit -nS

Чтобы вывести hard, используйте опцию -H:

ulimit -nH

Вы можете изменить ограничение, просто передав в ulimit новое значение:

ulimit -n 3000

Но поскольку hard-ограничение составляет 4000, то установить лимит больше этого значения вы не сможете. Чтобы изменить настройки ограничений для пользователя на постоянной основе, нужно настроить файл /etc/security/limits.conf. Синтаксис у него такой:

имя_пользователя тип_ограничения название_ограничения значение

Вместо имени пользователя можно использовать звездочку, чтобы изменения применялись ко всем пользователям в системе. Тип ограничения может быть soft или hard. Название — в нашем случае нужно nofile. И последний пункт — нужное значение. Установим максимум — 1617596.

sudo vi /etc/security/limits.conf

* hard nofile 1617596
* soft nofile 1617596

Нужно установить значение для soft и hard параметра, если вы хотите, чтобы изменения вступили в силу. Также убедитесь, что в файле /etc/pam.d/common-session есть такая строчка:

session required pam_limits.so

Если её нет, добавьте в конец. Она нужна, чтобы ваши ограничения загружались при авторизации пользователя.

Если вам нужно настроить ограничения только для определенного сервиса, например  Apache или Elasticsearch, то для этого не обязательно менять все настройки в системе. Вы можете сделать это с помощью systemctl. Просто выполните:

sudo systemctl edit имя_сервиса

И добавьте в открывшейся файл такие строки:

[Service]
LimitNOFILE=1617596
LimitNOFILESoft=1617596

Здесь мы устанавливаем максимально возможное ограничение как для hard- так и для soft-параметра. Дальше нужно закрыть этот файл и обновить конфигурацию сервисов:

sudo systemctl daemon-reload

Затем перезагрузить нужный сервис:

sudo systemctl restart имя_сервиса

Убедится, что для вашего сервиса применились нужные ограничения, можно, открыв файл по пути /proc/pid_сервиса/limits. Сначала смотрим PID нужного нам сервиса:

ps aux | grep elasticsearch

Затем смотрим информацию:

cat /proc/8388/limits

Выводы

В этой небольшой статье мы разобрали, что делать, если возникает ошибка «слишком много открытых файлов Linux», а также как изменять ограничения на количество открытых файлов для пользователя и процесса в Linux.

Об авторе

Содержание:

1.       Об ошибке при выполнении файловой операции

2.       Устранение «Ошибки при выполнении файловой операции» в 1С 8.3   

1.    Об ошибке при выполнении файловой операции

Приветствую, коллеги! В данной статье будет описана ошибка «Ошибка при выполнении файловой операции», и подробно рассмотрены способы ее устранения.

Когда происходит обновление конфигураций в 1С 8, по завершении обновления, часто появляется ошибка, которая гласит «Ошибка при выполнении файловой операции – файл не содержит доступных обновлений».  

2.    Устранение «Ошибки при выполнении файловой операции» в 1С 8.3

Рассмотрим методы, при помощи которых, можно устранить ошибку при выполнении файловой операции в 1С.

Итак, первый способ – это попробовать сделать обновление при помощи файлов по обновлению вида «релиз 1с*.cfu». Если это не помогло, то можно попробовать обновить систему при помощи общего файла вида «полный релиз 1С*.cf».

Вторым способом будет проверка на соответствие общей версии системы 1С с минимальными требованиями версии конфигурации 1С, которую обновляем.

Третий способ устранения ошибки при выполнении файловой операции в 1С – более сложный, но действенный. Необходимо открыть в конфигурацию от поставщика в режиме Конфигуратора. Если ошибка всё так же появляется, то необходимо удалить конфигурацию поставщика, а затем опять установить. По сути, в данном варианте «вытягивается» последняя, рабочая версия данной конфигурации и обновление будет завершено без ошибок.

Рассмотрим подробнее третий способ. Пусть у нас уже есть некоторая конфигурация 1С KORG 1-ой версии, которая работает, но нужно поставить 2-ю версию, то есть обновить версию конфигурации 1С 8.3. Когда происходит обновление, всплывает ошибка «Ошибка при выполнении файловой конфигурации». Порядок действий в этом случае:

1.     скачать релиз 1С KORG с версией 1*.cf;

2.     копируем нашу базу данных;

3.     в конфигураторе, который соответствует обновляемой базе, переходим по пути: «Конфигурация → Поддержка → Настройки поддержки → Снять с поддержки». В случае, если кнопка для снятия с поддержки недоступна, необходимо сперва включить возможные изменения. После этого нужно дать согласие, если система 1С будет уточнять что-либо или подтверждать действия;

4.     Далее переходим по следующему пути: «Конфигурация → Сравнить и объединить с конфигурацией из файла…». Здесь необходимо выбрать файл «полный релиз 1С KORG версии 1*.cf»;

5.     Далее перед нами появится окно, в котором система 1С будет запрашивать постановление на учёт для поддержки, на это уведомление обязательно отвечаем согласием;

6.     В случае, если наша конфигурация является типовой, откроется окно по сравнению конфигураций. В нем обязательно убираем все «галочки». Далее последует объединение конфигураций;

7.     В новом окне кликаем на «Сохранить изменения»;

8.     Ещё раз сохраняем базу данных;

9.     Обновляем конфигурацию 1С стандартным способом.

Если всё сделать, согласно инструкции выше, то в вашей конфигурации 1С 8.3 «Ошибка при выполнении файловой операции» больше не возникнет. Спасибо за внимание!

Специалист компании «Кодерлайн»

Айдар Фархутдинов

Ошибки СУБД. 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 и она будет работать нормально!

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

Источник

Обновлено 15.10.2020

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Рунета Pyatilistnik.org. В прошлый раз мы с вами разобрали, что из себя  представляет файловая система raw, и как ее исправить, чтобы восстановить свои данные. Двигаемся дальше и поговорим сегодня на тему  капризности 1С, точнее на капризную работу в рамках Windows Server 2016. Я рассмотрю причину и устранение периодически повторяющейся ошибки на сервере 1С 8.3 «Ошибка при выполнении файловой операции«. Ее я стал встречать после обновления с Windows Server 2012 R2 д 2016. Думаю мой опыт сэкономит вам часик серфинга по интернету.

Описание проблемы

В моей компании заканчивается обновление операционных систем у виртуальных серверов, с Windows Server 2012 R2 на Windows Server 2016, я понимаю, что поддержка первых еще будет несколько лет, но хочется уже не делать это в последний момент, а слегка опережать, да и уже давно пора стремиться к Windows Server 2019. Сервера 1С не были исключением, обновление происходило по быстрому варианты. Тут подразумевается накатывание более новой версии ОС по верх старой, тут мы убивали двух зайцев:

1. Получали свежую версию ОС
2. Оставляли весь софт на сервере, и не требовалась его переустановка

В случае чего всегда можно было откатиться из снапшота на момент проведения работ, благо ESXI 6.5 это помогает делать в два клика. Все прекрасно обновилось и сервер зажил новой жизнью. В какой-то момент при запуске клиента 1С 8.3 на RDS ферме, стала появляться ошибка:

Устранение проблемы

Начав изучать данный вопрос мы не стали откатываться к бэкапу, так как данная проблема возникала не постоянно, а через некоторые промежутки и была вызвана явно не переходом на более новую версию операционной системы. Подняв исторические данные в системе заявок, я нашел похожую, где решением ошибки был перенос базы данных 1С на другой диск. Меня это заинтересовало и я стал прикидывать, что же могло быть в той ситуации. Через минут 20 я нашел одну закономерность, что на всех проблемных хостах был установлен компонент Windows дедупликации, как раз на тех дисках, где располагались базы данных 1С.

Я для тестирования отключил дедупликацию и вернул все в исходное состояние, и о чудо ошибка при выполнении файловой операции больше не появлялась. Все те же действия я произвел и на остальных серверах.

Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.

Вообще если у вас виртуальные сервера лежат на системе хранения данных, то у нее должна быть своя функция дедупликации и использовать лучше и правильнее ее. Если у вас есть другие варианты решения данной проблемы, то пишите их в комментариях. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.