Psql не удалось подключиться к серверу, нет такого файла или каталога
Обновлено: 30.06.2024
В статье описывается, как устранить указанное выше сообщение об ошибке. Было много статей, обсуждающих этот тип ошибки. Один из них доступен по следующей ссылке. Полное сообщение об ошибке находится в следующей строке:
Как видно из сообщения об ошибке, использование команды «psql» с дополнительным параметром пользователя с использованием «postgres» не позволяет подключиться к базе данных PostgreSQL. Чтобы решить проблему, предпринимаются следующие шаги, чтобы причина проблемы больше не была доступна.
<р>1. Проверьте состояние службы базы данных PostgreSQL. Обычно следующая команда предназначена для проверки состояния службы:Эта команда зависит от конфигурации службы установки базы данных PostgreSQL. Обычно, если появляется следующий вывод, служба PostgreSQL работает нормально:
В приведенном выше выполнении команды для проверки состояния базы данных PostgreSQL используется сценарий, существующий в /etc/init.d.
<р>2. Проверьте состояние порта службы базы данных PostgreSQL. Обычно он прослушивает 5432. Следующая команда является выполнением команды для проверки состояния порта: <р>3. И последнее, но не менее важное: проверьте права на подключение к серверу базы данных PostgreSQL. Основные правила доступа к серверу базы данных PostgreSQL находятся в файле pg_hba.conf. Он доступен в папке данных сервера баз данных PostgreSQL. Например, в /opt/postgresql/data. Эта папка является результатом выполнения команды «initdb». Дополнительные сведения об использовании «initdb» см. в статье «Как активировать службу базы данных PostgreSQL» по этой ссылке. Файл pg_hba.conf по умолчанию будет иметь для примера следующее содержимое:Как показано в приведенном выше примере, все соединения исходят от локального сервера базы данных PostgreSQL с использованием любых пользователей и к любым типам баз данных будут иметь значение «доверие» в методе аутентификации. Другими словами, нет необходимости в каком-либо дополнительном параметре «-p» для указания или предоставления пароля для подключения к серверу базы данных PostgreSQL с использованием любых пользователей, и в контексте этой статьи это «postgres».
Я пытаюсь запустить psql на своей машине Vagrant, но получаю следующую ошибку:
Команды EDIT, которые я использовал для установки и запуска postgres:
- sudo apt-get update
- sudo apt-get установить postgresql
- sudo su postgres
- psql -d postgres -U postgres
31 Ответ 31
У меня была такая же проблема, связанная с конфигурацией моего файла pg_hba.conf (расположенного в /etc/postgresql/9.6/main ). Обратите внимание, что я использую версию postgresql 9.6.
Сама ошибка связана с неправильной настройкой postgresql, что приводит к сбою сервера до его запуска.
Я бы посоветовал следовать этим инструкциям:
- Подтвердите, что служба postgresql запущена, используя sudo service postgresql start
- Запустите pg_lsclusters со своего терминала
Проверьте, какой у вас кластер. Вывод должен выглядеть примерно так:
Версия — Каталог данных владельца статуса порта кластера
9.6 ------- main -- 5432 онлайн postgres /var/lib/postgresql/9.6/main
Не обращайте внимания на знаки '---', так как они используются только для выравнивания. Важной информацией являются версия и кластер. Вы также можете проверить, работает ли сервер, в столбце состояния.
2017-07-13 16:53:04 BRT 32176 ЖУРНАЛ: неверный метод аутентификации "все"
2017-07-13 16:53:04 BRT 32176 КОНТЕКСТ: строка 90 файла конфигурации "/etc/postgresql/9.5/main/pg_hba.conf"
2017-07-13 16:53:04 BRT 32176 FATAL: не удалось загрузить pg_hba.conf< /p>
Я много искал, чтобы найти это, спасибо этому сообщению.
На шаге 4 мне пришлось выполнить sudo systemctl start postgresql@9.5-main вместо pg_ctlcluster 9.5 main start . Спасибо за прекрасное объяснение!
на моем я не могу запустить это: "pg_ctlcluster 10 main start" вместо этого у меня работает: "/usr/lib/postgresql/10/bin/pg_ctl restart -D /var/lib/postgresql/10/main "Конечно, вы должны указать свою собственную версию postgre и путь. Я забыл, где я взял это решение, но оно есть в истории моего терминала. Может кому надо. спасибо за этот ответ, это привело меня в правильном направлении.
Запуск pg_ctlcluster, поскольку пользователь postgres выдал мне сообщение об ошибке, которое мне было нужно напрямую. Для меня лучше, чем sudo pg_ctlcluster. Но я использую Postgres 12 или 13.
Как я это исправил (mac)
- Попробуйте запустить postgresql командой pg_ctl -D /usr/local/var/postgres start
- Ищите сообщение об ошибке, в котором говорится что-то вроде FATAL: не удалось открыть каталог "pg_tblspc": Нет такого файла или каталога.
- Создайте отсутствующий каталог mkdir /usr/local/var/postgres/pg_tblspc
- Повторяйте с первого шага, пока не создадите все недостающие каталоги.
- Когда вы закончите, а затем снова попытаетесь запустить postgresql, он может сказать FATAL: файл блокировки "postmaster.pid" уже существует
- Удалите postmaster.pid: rm /usr/local/var/postgres/postmaster.pid
- Запустите postgres командой: pg_ctl -D /usr/local/var/postgres start
- Готово ✨
Эти два шага помогли мне решить проблему на Mac:
Если вы столкнулись с этой проблемой (сообщил @luckyguy73): psql: FATAL: база данных "postgresql" не существует
спасибо, приятель, я перешел от невозможности подключения к фатальной, следуя вашим инструкциям: "psql: FATAL: база данных "postgresql" не существует"
Не беспокойтесь, на самом деле все в порядке. я только что запустил 'brew postgresql-upgrade-database', и это помогло, спасибо
Рад, что вы исправили это! Если вы не возражаете, я тоже добавлю это к ответу, если кто-то еще столкнется с той же проблемой. Спасибо
После отключения электроэнергии у меня всегда возникает эта проблема на моем Mac для разработчиков. У меня всегда работало удаление файла .pid, в моем случае это: rm /usr/local/var/postgresql@9.6/postmaster.pid
Я просто публикую это для всех, кто чувствует себя потерянным и безнадежным, как я, когда нашел этот вопрос. Кажется, что иногда, редактируя некоторые файлы конфигурации, связанные с psotgresql, можно случайно изменить права доступа к файлу:
Обратите внимание, что pg_hba.conf принадлежит root, и пользователи не могут даже прочитать его. Это приводит к тому, что postgres не может открыть этот файл и, следовательно, не может запустить сервер, выдавая ошибку, показанную в исходном вопросе.
Мне удалось снова сделать этот файл доступным для пользователя postgres, а затем после запуска
Удалось снова запустить сервер.
Да, это была моя проблема, и в логах это не указывалось (а если и было, то я не так понял).
Не совсем то, что случилось со мной, но по какой-то причине СЕТЕВАЯ СЛУЖБА потеряла права на запись во всю структуру каталогов. Этот ответ указал мне правильное направление, поэтому я проголосовал за него.
ВНИМАНИЕ: база данных будет удалена
Спасибо, @Tucker Watts и @Gaurav Verma. Я решил свою проблему, попробовав оба решения и добавив эту команду pg_ctl -D /usr/local/var/postgres -l logfile start .
Показывает ли файл /etc/postgresql/9.6/main/postgresql.conf, что назначенный порт? Насколько я помню, при установке Xubuntu Linux по умолчанию у меня по какой-то причине отображался порт = 5433, но я закомментировал строку в том же файле, в которой говорилось listen_addresses = 'localhost', и раскомментировал строку listen_addresses = '*' . Так что, может быть, начать и проверить там. Надеюсь, это поможет.
Это работает для меня:
ВНИМАНИЕ: база данных будет удалена
Это единственное, что помогло мне после бесчисленных часов устранения неполадок.
Мне удалось решить проблему, запустив:
В моем случае причиной проблемы был файл блокировки postmaster.id, который не был должным образом удален во время последнего системного сбоя. Удаление его с помощью sudo rm /usr/local/var/postgres/postmaster.pid и перезапуск Postgres решило проблему.
В моем случае Postgres управлялся через Homebrew Services (т. е. запускался с помощью команды brew services start postgresql@10 Terminal для Postgres 10, который я использую), и для этой настройки мне нужно было выполнить пару важных шагов, прежде чем я могу применить любой совет в этой теме. Поэтому я хочу поделиться только этим фрагментом, так как он может помочь тем, у кого такие же настройки.
ПРИМЕЧАНИЕ: все приведенные ниже команды следует запускать в Терминале.
Чтобы дать краткую информацию: после обновления до macOS Big Sur я обнаружил, что Postgres не работает, а запуск psql приводит к ошибке, упомянутой в исходном вопросе выше.Я попытался запустить Postgres (через команду brew services start postgresql@10), в результате появилось сообщение Service postgresql@10 уже запущено. Если я попытался перезапустить его (через перезапуск сервисов brew postgresql@10 ), я получил сообщение о том, что он был остановлен, а затем успешно запущен. Но! Это было вводящее в заблуждение сообщение, и я потратил довольно много времени на поиск проблем с конфигурацией и т. д., прежде чем обнаружил, что на самом деле служба не была успешно запущена.
Сначала я хочу начать с того, что наиболее релевантный ответ был здесь. Когда я пытаюсь запустить следующее, я получаю следующее:
Я также могу подтвердить, что сервер запускается и завершает работу, выполнив первую команду ниже. Вторая команда ниже подтверждает, что сервер запустился, но сразу же закрылся,
Ответ, который кажется многообещающим:
Я установил
- sudo apt-get установить postgresql
- sudo apt-get install postgresql-client-common
- sudo apt-get установить postgresql-client
- PostgreSQL-9.6.5 для Ubuntu 16.04 через установщик (но это может быть излишним).
Наконец, деинсталлятор, найденный в /opt/PostgreSQL/9.6, даже не удаляет все из моей системы так, как должен. У меня осталось окно с оставшимися файлами после удаления. Если бы вы могли помочь мне исправить проблему с невозможностью подключения к серверу вверху, это было бы предпочтительнее. В крайнем случае я был бы готов стереть все начисто, но пока безуспешно.
2 ответа 2
PostgreSQL-9.6.5 для Ubuntu 16.04 через установщик (но это может быть излишним)
Это не лишнее, вы установили две разные версии Postgres в двух разных местах. В системе управления пакетами, такой как Ubuntu (и большинстве разновидностей Linux), вы должны только использовать версию программного обеспечения, найденную в диспетчере пакетов. Вероятно, вы использовали установщик с их веб-сайта, который установил Postgres либо в /opt/, либо в /usr/local/ и изменил целевые файлы systemd, чтобы они указывали на эту установку. Тем временем ваш клиент приходит из диспетчера пакетов и ожидает, что сокет домена UNIX, к которому он подключается, находится в /var/run .
Если это одноразовая виртуальная машина, сотрите ее, переустановите и устанавливайте Postgres только через apt-get . Если нет, посмотрите, можете ли вы удалить загруженный пакет и переустановить другие пакеты с помощью apt-get (мы надеемся, что это исправит ваши целевые файлы systemd, чтобы они указывали на нужное место).
Прежде чем кто-либо сможет получить доступ к базе данных, вы должны запустить сервер базы данных. Программа сервера базы данных называется postgres. Программа postgres должна знать, где найти данные, которые она должна использовать. Это делается с помощью параметра -D. Таким образом, самый простой способ запустить сервер:
что оставит сервер работающим на переднем плане. Это необходимо сделать, войдя в учетную запись пользователя PostgreSQL. Без -D сервер попытается использовать каталог данных, указанный в переменной среды PGDATA. Если эта переменная также не указана, произойдет сбой.
Обычно лучше запускать postgres в фоновом режиме. Для этого используйте обычный синтаксис оболочки Unix:
Важно где-то хранить выходные данные сервера stdout и stderr, как показано выше. Это поможет в целях аудита и диагностики проблем. (См. Раздел 23.3 для более подробного обсуждения обработки файла журнала.)
Программа postgres также принимает ряд других параметров командной строки. Для получения дополнительной информации см. справочную страницу postgres и главу 18 ниже.
Этот синтаксис оболочки может быстро надоесть. Поэтому программа-оболочка pg_ctl предназначена для упрощения некоторых задач. Например:
запустит сервер в фоновом режиме и поместит вывод в указанный файл журнала. Параметр -D здесь имеет то же значение, что и для postgres. pg_ctl также может остановить сервер.
Обычно сервер базы данных нужно запускать при загрузке компьютера. Сценарии автозапуска зависят от операционной системы. Некоторые из них распространяются вместе с PostgreSQL в каталоге contrib/start-scripts. Для его установки потребуются привилегии root.
В разных системах используются разные правила запуска демонов во время загрузки. Во многих системах есть файл /etc/rc.local или /etc/rc.d/rc.local. Другие используют каталоги rc.d. Что бы вы ни делали, сервер должен запускаться под учетной записью пользователя PostgreSQL, а не под root или любым другим пользователем. Поэтому вам, вероятно, следует формировать свои команды, используя su postgres -c '. '. Например:
Вот еще несколько предложений для конкретных операционных систем. (В каждом случае обязательно используйте правильный каталог установки и имя пользователя, где мы показываем общие значения.)
Для FreeBSD просмотрите файл contrib/start-scripts/freebsd в исходном дистрибутиве PostgreSQL.
В OpenBSD добавьте следующие строки в файл /etc/rc.local:
В системах Linux добавьте
в /etc/rc.d/rc.local или посмотрите файл contrib/start-scripts/linux в исходном дистрибутиве PostgreSQL.
В NetBSD используйте сценарии запуска FreeBSD или Linux, в зависимости от предпочтений.
В Solaris создайте файл с именем /etc/init.d/postgresql, содержащий следующую строку:
Затем создайте символическую ссылку на него в /etc/rc3.d как S99postgresql.
17.3.1. Сбои при запуске сервера
Существует несколько распространенных причин, по которым сервер может не запуститься. Проверьте файл журнала сервера или запустите его вручную (без перенаправления стандартного вывода или стандартной ошибки) и посмотрите, какие сообщения об ошибках появляются. Ниже мы более подробно объясним некоторые из наиболее распространенных сообщений об ошибках.
Обычно это означает именно то, что предполагает: вы попытались запустить другой сервер на том же порту, на котором уже запущен один. Однако, если сообщение об ошибке ядра не является адресом, который уже используется, или каким-либо его вариантом, может возникнуть другая проблема. Например, при попытке запустить сервер на зарезервированном номере порта может появиться что-то вроде:
вероятно, это означает, что ограничение вашего ядра на размер разделяемой памяти меньше, чем рабочая область, которую пытается создать PostgreSQL (4011376640 байт в этом примере). Или это может означать, что в вашем ядре вообще не настроена поддержка разделяемой памяти в стиле System-V. В качестве временного обходного пути вы можете попробовать запустить сервер с меньшим, чем обычно, количеством буферов (shared_buffers). Со временем вы захотите перенастроить ядро, чтобы увеличить разрешенный размер разделяемой памяти. Вы также можете увидеть это сообщение при попытке запустить несколько серверов на одном компьютере, если их общее запрашиваемое пространство превышает ограничение ядра.
не означает, что у вас закончилось место на диске. Это означает, что ограничение вашего ядра на количество семафоров System V меньше, чем количество, которое хочет создать PostgreSQL. Как и выше, вы можете обойти проблему, запустив сервер с уменьшенным числом разрешенных подключений (max_connections), но в конечном итоге вы захотите увеличить ограничение ядра.
Если вы получаете сообщение об ошибке "недопустимый системный вызов", вполне вероятно, что совместно используемая память или семафоры вообще не поддерживаются вашим ядром. В этом случае единственный вариант — перенастроить ядро, чтобы включить эти функции.
17.3.2. Проблемы с подключением клиента
Хотя условия ошибки, возможные на стороне клиента, довольно разнообразны и зависят от приложения, некоторые из них могут быть напрямую связаны с тем, как был запущен сервер. Условия, отличные от показанных ниже, должны быть задокументированы в соответствующем клиентском приложении.
Это типичная ошибка "Я не могу найти сервер для связи". Это выглядит так, как показано выше, при попытке связи по протоколу TCP/IP. Распространенной ошибкой является забывание настроить сервер для разрешения подключений TCP/IP.
В качестве альтернативы вы получите это сообщение при попытке установить связь через сокет домена Unix с локальным сервером:
Последняя строка полезна для проверки того, что клиент пытается подключиться к нужному месту. Если на самом деле там не работает сервер, сообщение об ошибке ядра обычно будет либо «Отказано в подключении», либо «Нет такого файла или каталога», как показано на рисунке. (Важно понимать, что отказ в подключении в этом контексте не означает, что сервер получил ваш запрос на подключение и отклонил его. В этом случае будет выдано другое сообщение, как показано в Разделе 19.4.) Другие сообщения об ошибках, такие как Время ожидания подключения истекло, могут указывают на более серьезные проблемы, такие как отсутствие сетевого подключения.
Читайте также: