Postgresql не удалось создать сокеты tcp ip
Чтобы кто-либо смог обратиться к базе данных, необходимо сначала запустить сервер баз данных. Программа сервера называется postgres .
Если вы используете PostgreSQL в виде готового продукта, в нём наверняка реализована возможность запуска сервера в виде фонового задания так, как это принято в вашей операционной системе. Использовать предоставленную продуктом инфраструктуру для запуска сервера гораздо проще, чем пытаться разобраться, как это сделать самостоятельно. За подробностями обратитесь к документации используемого вами продукта.
Самый прямолинейный вариант запуска сервера вручную — просто выполнить непосредственно postgres , указав расположение каталога данных в ключе -D , например:
В результате сервер продолжит работу на переднем плане. Запускать эту команду следует под именем учётной записи PostgreSQL . Без параметра -D сервер попытается использовать каталог данных, указанный в переменной окружения PGDATA . Если и эта переменная не определена, сервер не запустится.
Однако обычно лучше запускать postgres в фоновом режиме. Для этого можно применить обычный синтаксис, принятый в оболочке Unix:
Важно где-либо сохранять информацию, которую выводит сервер в каналы stdout и stderr , как показано выше. Это полезно и для целей аудита, и для диагностики проблем. (Более глубоко работа с файлами журналов рассматривается в Разделе 25.3.)
Программа postgres также принимает несколько других параметров командной строки. За дополнительными сведениями обратитесь к справочной странице postgres и к следующей Главе 20.
Такой вариант запуска довольно быстро может оказаться неудобным. Поэтому для упрощения подобных задач предлагается вспомогательная программа pg_ctl . Например:
Обычно возникает желание, чтобы сервер баз данных сам запускался при загрузке операционной системы. Скрипты автозапуска для разных систем разные, но в составе PostgreSQL предлагается несколько типовых скриптов в каталоге contrib/start-scripts . Для установки такого скрипта в систему требуются права root.
В различных системах приняты разные соглашения о порядке запуска служб в процессе загрузки. Во многих системах для этого используется файл /etc/rc.local или /etc/rc.d/rc.local . В других применяются каталоги init.d или rc.d . Однако при любом варианте запускаться сервер должен от имени пользователя PostgreSQL , но не root или какого-либо другого пользователя. Поэтому команду запуска обычно следует записывать в форме su postgres -c '. ' . Например:
Ниже приведены более конкретные предложения для нескольких основных ОС. (Вместо указанных нами шаблонных значений необходимо подставить правильный путь к каталогу данных и фактическое имя пользователя.)
Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода PostgreSQL .
В OpenBSD , добавьте в файл /etc/rc.local следующие строки:
В системах Linux вы можете либо добавить
в /etc/rc.d/rc.local или в /etc/rc.local , либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода PostgreSQL .
Используя systemd , вы можете применить следующий файл описания службы (например, /etc/systemd/system/postgresql.service ):
Для использования Type=notify требуется, чтобы сервер был скомпилирован с указанием configure --with-systemd .
Особого внимания заслуживает значение тайм-аута. На момент написания этой документации по умолчанию в systemd принят тайм-аут 90 секунд, так что процесс, не сообщивший о своей готовности за это время, будет уничтожен. Но серверу PostgreSQL при запуске может потребоваться выполнить восстановление после сбоя, так что переход в состояние готовности может занять гораздо больше времени. Предлагаемое значение infinity отключает логику тайм-аута.
В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux , в зависимости от предпочтений.
В Solaris , создайте файл с именем /etc/init.d/postgresql , содержащий следующую стоку:
17.3.1. Сбои при запуске сервера
не означает, что у вас закончилось место на диске. Это значит, что установленное в вашем ядре предельное число семафоров System V меньше, чем количество семафоров, которое пытается создать PostgreSQL . Как и в предыдущем случае, можно попытаться обойти эту проблему, запустив сервер с меньшим числом допустимых подключений (max_connections), но в конце концов вам придётся увеличить этот предел в ядре.
Если вы получаете ошибку "illegal system call" (неверный системный вызов), то, вероятнее всего, ваше ядро вовсе не поддерживает разделяемую память или семафоры. В этом случае, вам остаётся только переконфигурировать ядро и включить их поддержку.
17.3.1. Сбои при запуске сервера
не означает, что у вас закончилось место на диске. Это значит, что установленное в вашем ядре предельное число семафоров System V меньше, чем количество семафоров, которое пытается создать Postgres Pro . Как и в предыдущем случае можно попытаться обойти эту проблему, запустив сервер с меньшим числом допустимых подключений (max_connections), но в конце концов вам придётся увеличить этот предел в ядре.
Если вы получаете ошибку « illegal system call » (неверный системный вызов), то, вероятнее всего, ваше ядро вовсе не поддерживает разделяемую память или семафоры. В этом случае вам остаётся только переконфигурировать ядро и включить их поддержку.
Шаг 5: Проверьте, что пользователь postgres принадлежит к группе пользователей ssl-cert
В моем случае это было вызвано опечаткой, которую я сделал при редактировании /etc/postgresql/9.5/main/pg_hba.conf
Но MD5 должен был быть в нижнем регистре md5 :
Это ответ, который исправил это для меня :) Я ранее поменял свой trusted вместо trust , и не перезапустил службу, и он сломался только на следующий день, когда я уже забыл, что я изменил
Я обнаружил, что удаление Postgres звучит неубедительно. Это помогает решить мою проблему:
Запустите сервер postgres:
Убедитесь, что сервер запускается при загрузке:
Подробную информацию можно найти на сайте DigitalOcean здесь.
Во-первых, отключите все параметры ведения журнала в postgresql.conf. Это раздел:
Закомментируйте все в этом разделе. Затем перезапустите сервис.
При перезапуске используйте /etc/init.d/postgresql start или restart я нашел полезным находиться в режиме суперпользователя при перезапуске. У меня было открыто окно x только для этой операции. Вы можете установить этот режим суперпользователя с помощью sudo -i .
Убедитесь, что к серверу можно подключиться с помощью этой простой команды: psql -l -U postgres
Если это не помогает, то подумайте:
Я менял владельца многих папок, пытаясь найти решение. Я знал, что я, вероятно, буду пытаться вернуть владельцам этих папок еще chmod два дня. Если вы уже перепутали владельцев этих папок и не хотите полностью очищать свой сервер, начните отслеживать настройки всех затронутых папок, чтобы вернуть их в исходное состояние. Возможно, вы захотите попробовать выполнить параллельную установку в другой системе и систематически проверять владение и настройки всех папок. Утомительно, но вы можете получить доступ к своим данным.
Как и некоторые другие, я получаю эту ошибку, когда запускаю rake db: migrate в своем проекте или даже пробую большинство задач с базами данных для моих приложений Ruby on Rails 3.2.
PGError (не удалось подключиться к серверу: такого файла или каталога нет. Сервер работает локально и принимает подключения через сокет домена Unix "/tmp/.s.PGSQL.5432"?
Я установил PostgreSQL вместе с Homebrew очень давно, и после недавней попытки установить MongoDB моя установка PostgreSQL никогда не была прежней. Я использую OS X v10.6 Snow Leopard.
Что не так и как мне лучше понять, как PostgreSQL должен и должен быть установлен на моем Mac?
Пока (я думаю) это говорит мне о том, что PostgreSQL не работает (?).
Но говорит ли это, что PostgreSQL работает?
PS: ~/Library/LaunchAgents включает в себя два файла PostgreSQL .plist. Я не уверен, что это актуально.
Я попробовал следующее и получил результат, как показано ниже.
$ psql -p 5432 -h localhost
С тех пор я читал, что это происходит потому, что OS X устанавливает свою собственную версию PostgreSQL, а Homebrew устанавливает другую версию в другом месте, а команды PostgreSQL находятся в каталоге / tmp /. Вам нужно будет поискать больше о переполнении стека, но в основном вы используете символическую ссылку PostgreSQL, чтобы все, что просматривает этот путь tmp, действительно находило реальный путь, если это имеет смысл.
Это ссылка, в которой я нашел несколько вещей, которые можно попробовать, в частности, используя символическую ссылку, как указано выше, Mac OSX Lion Postgres не принимает соединения в /tmp/.s.PGSQL.5432 . Я все еще хотел бы, чтобы кто-нибудь собрал достойное объяснение концепций, лежащих в основе установки PostgreSQL на OS X, и почему все это так сложно.
Последние идеи, которые помогут с устранением неполадок:
Главное, что нужно принять во внимание, это:
Убедитесь, что запись пути для копии PostgreSQL, которую вы хотите запустить, COMES ДО пути к PostgreSQL системы OS X.
Это основное требование, которое решает, какой PostgreSQL будет запущен, и, как мне говорят, приводит к большинству из этих проблем.
Чтобы кто-либо смог обратиться к базе данных, необходимо сначала запустить сервер баз данных. Программа сервера называется postgres. Для работы программа postgres должна знать, где найти данные, которые она будет использовать. Указать это местоположение позволяет параметр -D. Таким образом, проще всего запустить сервер, выполнив команду:
в результате которой сервер продолжит работу в качестве процесса переднего плана. Запускать эту команду следует под именем учётной записи PostgreSQL . Без параметра -D сервер попытается использовать каталог данных, указанный в переменной окружения PGDATA. Если и эта переменная не определена, сервер не будет запущен.
Однако обычно лучше запускать postgres в фоновом режиме. Для этого можно применить обычный синтаксис, принятый в оболочке Unix:
Важно где-либо сохранять информацию, которую выводит сервер в каналы stdout и stderr , как показано выше. Это полезно и для целей аудита, и для диагностики проблем. (Более глубоко работа с файлами журналов рассматривается в Разделе 23.3.)
Программа postgres также принимает несколько других параметров командной строки. За дополнительными сведениями обратитесь к справочной странице postgres и к следующей Главе 18.
Такой вариант запуска довольно быстро может оказаться неудобным. Поэтому для упрощения подобных задач предлагается вспомогательная программа pg_ctl . Например:
Обычно возникает желание, чтобы сервер баз данных сам запускался при загрузке операционной системы. Скрипты автозапуска для разных систем разные, но в составе PostgreSQL предлагается несколько типовых скриптов в каталоге contrib/start-scripts. Для установки такого скрипта в систему требуются права root.
В различных системах приняты разные соглашения о порядке запуска служб в процессе загрузки. Во многих системах для этого используется файл /etc/rc.local или /etc/rc.d/rc.local. В других применяются каталоги init.d или rc.d. Однако при любом варианте запускаться сервер должен от имени пользователя PostgreSQL , но не root или какого-либо другого пользователя. Поэтому команду запуска обычно следует записывать в форме su postgres -c '. '. Например:
Ниже приведены более конкретные предложения для нескольких основных ОС. (Вместо указанных нами шаблонных значений необходимо подставить правильный путь к каталогу данных и фактическое имя пользователя.)
Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода PostgreSQL .
В OpenBSD , добавьте в файл /etc/rc.local следующие строки:
В системах Linux вы можете либо добавить
в /etc/rc.d/rc.local или в /etc/rc.local, либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода PostgreSQL .
В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux , в зависимости от предпочтений.
В Solaris , создайте файл с именем /etc/init.d/postgresql, содержащий следующую стоку:
19.3.1. Сбои при запуске сервера
не означает, что у вас закончилось место на диске. Это значит, что установленное в вашем ядре предельное число семафоров System V меньше, чем количество семафоров, которое пытается создать PostgreSQL . Как и в предыдущем случае можно попытаться обойти эту проблему, запустив сервер с меньшим числом допустимых подключений (max_connections), но в конце концов вам придётся увеличить этот предел в ядре.
Шаг 4: проверьте право собственности на postgres
Убедитесь, что postgres это владелец /var/lib/postgresql/version_no/main
Если нет, запустите
Шаг 3: Шаг 2 не удался и выдал ошибку
Если этот процесс не будет успешным, он выдаст ошибку. Вы можете увидеть журнал ошибок на /var/log/postgresql/postgresql-9.6-main.log
Моя ошибка была:
Шаг 2: перезапустите pg_ctlcluster
17.3.2. Проблемы с подключениями клиентов
Хотя ошибки подключений, возможные на стороне клиента, довольно разнообразны и зависят от приложений, всё же несколько проблем могут быть связаны непосредственно с тем, как был запущен сервер. Описание ошибок, отличных от описанных ниже, следует искать в документации соответствующего клиентского приложения.
При установке двоичных пакетов в системах Linux базы данных по умолчанию располагаются в каталоге /var/lib/pgpro/std-11/data , если явно не будет задан другой каталог. За подробностями обратитесь к Разделу 16.1.
Чтобы кто-либо смог обратиться к базе данных, необходимо сначала запустить сервер баз данных. Программа сервера называется postgres . Для работы программа postgres должна знать, где найти данные, которые она будет использовать. Указать это местоположение позволяет параметр -D . Таким образом, проще всего запустить сервер, выполнив команду:
в результате которой сервер продолжит работу в качестве процесса переднего плана. Запускать эту команду следует под именем учётной записи Postgres Pro . Без параметра -D сервер попытается использовать каталог данных, указанный в переменной окружения PGDATA . Если и эта переменная не определена, сервер не будет запущен.
Однако обычно лучше запускать postgres в фоновом режиме. Для этого можно применить обычный синтаксис, принятый в оболочке Unix:
Важно где-либо сохранять информацию, которую выводит сервер в каналы stdout и stderr , как показано выше. Это полезно и для целей аудита, и для диагностики проблем. (Более глубоко работа с файлами журналов рассматривается в Разделе 23.3.)
Программа postgres также принимает несколько других параметров командной строки. За дополнительными сведениями обратитесь к справочной странице postgres и к следующей Главе 18.
Такой вариант запуска довольно быстро может оказаться неудобным. Поэтому для упрощения подобных задач предлагается вспомогательная программа pg_ctl . Например:
Обычно возникает желание, чтобы сервер баз данных сам запускался при загрузке операционной системы. Скрипты автозапуска для разных систем разные, но в составе Postgres Pro предлагается несколько типовых скриптов в каталоге contrib/start-scripts . Для установки такого скрипта в систему требуются права root.
В различных системах приняты разные соглашения о порядке запуска служб в процессе загрузки. Во многих системах для этого используется файл /etc/rc.local или /etc/rc.d/rc.local . В других применяются каталоги init.d или rc.d . Однако при любом варианте запускаться сервер должен от имени пользователя Postgres Pro , но не root или какого-либо другого пользователя. Поэтому команду запуска обычно следует записывать в форме su postgres -c '. ' . Например:
Ниже приведены более конкретные предложения для нескольких основных ОС. (Вместо указанных нами шаблонных значений необходимо подставить правильный путь к каталогу данных и фактическое имя пользователя.)
Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода Postgres Pro .
В OpenBSD , добавьте в файл /etc/rc.local следующие строки:
В системах Linux вы можете либо добавить
в /etc/rc.d/rc.local или в /etc/rc.local , либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода Postgres Pro .
Используя systemd , вы можете применить следующий файл описания службы (например, /etc/systemd/system/postgresql.service ):
Для использования Type=notify требуется, чтобы сервер был скомпилирован с указанием configure --with-systemd .
Особого внимания заслуживает значение тайм-аута. На момент написания этой документации по умолчанию в systemd принят тайм-аут 90 секунд, так что процесс, не сообщивший о своей готовности за это время, будет уничтожен. Но серверу Postgres Pro при запуске может потребоваться выполнить восстановление после сбоя, так что переход в состояние готовности может занять гораздо больше времени. Предлагаемое значение 0 отключает логику тайм-аута.
В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux , в зависимости от предпочтений.
В Solaris , создайте файл с именем /etc/init.d/postgresql , содержащий следующую стоку:
19.3.2. Проблемы с подключениями клиентов
Хотя ошибки подключений, возможные на стороне клиента, довольно разнообразны и зависят от приложений, всё же несколько проблем могут быть связаны непосредственно с тем, как был запущен сервер. Описание ошибок, отличных от описанных ниже, следует искать в документации соответствующего клиентского приложения.
Если сервер действительно работает, проверьте, что указываемый клиентом путь сокета (здесь /tmp ) соответствует значению unix_socket_directories.
Я установил стек Bitnami Django, который включал PostgreSQL 8.4.
При запуске psql -U postgres я получаю следующую ошибку:
PG определенно работает, и pg_hba.conf файл выглядит так:
«Доказательство», что pg работает:
Я понятия не имею, о чем вы спрашиваете, и вы никогда не предоставляли информацию. Это 100 человек, которые получают общую ошибку и сообщают о разных вещах. Это полностью вне формата для сайта.
Эта проблема возникает из-за установки postgres пакета без номера версии. Хотя postgres будет установлен и будет правильной версии, скрипт для настройки кластера не будет работать правильно; это проблема упаковки.
Если вам удобно, postgres есть скрипт, который вы можете запустить, чтобы создать этот кластер и postgres запустить его. Тем не менее, есть более простой способ.
Сначала удалите старую установку postgres. В настоящее время проблема заключается в 9.1, поэтому я буду считать, что это то, что вы установили
Теперь просто переустановите
Запишите название пакета с номером версии. НТН.
Работал для Ubuntu 16.04 и Postgres 9.5, но сначала должен был удалить каждый пакет, связанный с Postgres.
Я предполагаю, что сервер на самом деле слушает сокет, /tmp/.s.PGSQL.5432 а не тот /var/run/postgresql/.s.PGSQL.5432 , к которому ваш клиент пытается подключиться. Это типичная проблема при использовании скомпилированных вручную или сторонних пакетов PostgreSQL в Debian или Ubuntu, потому что исходным по умолчанию для каталога сокетов Unix-домена является, /tmp но пакет Debian меняет его на /var/run/postgresql .
Возможные обходные пути:
- Используйте клиентов, предоставленных вашим сторонним пакетом (звонок /opt/djangostack-1.3-0/postgresql/bin/psql ). Возможно, удалите все пакеты, поставляемые с Ubuntu (это может быть сложно из-за других обратных зависимостей).
- Исправьте каталог сокетов стороннего пакета, чтобы он был совместим с Debian / Ubuntu.
- -H localhost Вместо этого используйте для подключения через TCP / IP.
- Используйте -h /tmp или эквивалентную PGHOST настройку, чтобы указать на правильный каталог.
- Не используйте сторонние пакеты.
Это работает для меня:
Включить или добавить:
Перезапустите ядро базы данных:
Также вы можете проверить файл pg_hba.conf
И добавьте адрес своей сети или хоста:
listen_address = '*' сделал свое дело. он только слушал на "localhost", а не на 127.0.0.1. благодарю вас!
Боже мой . наконец то, что сработало - ничего больше не сработало, пока я не добавил адрес и не прокомментировал адрес для прослушивания.
Вы можете использовать, psql -U postgres -h localhost чтобы заставить соединение происходить по TCP вместо доменных сокетов UNIX; ваш netstat вывод показывает, что сервер PostgreSQL прослушивает порт 5432 локального хоста.
Вы можете узнать, какой локальный сокет UNIX используется сервером PostgrSQL, используя другой вызов netstat :
В любом случае, интерфейсы, на которых слушает сервер PostgreSQL, настроены в postgresql.conf .
Просто создайте мягкую ссылку, подобную этой:
Это сработало для меня и, казалось, было самым простым решением без изменения конфигурации postgresql. Будьте уверены, что вы являетесь суперпользователем при попытке сделать ссылку.
Я заставляю это работать этим:
Выберите предпочитаемые локали и запустите
(9.5 - это моя версия postgresql)
и тогда это работает!
Ха, извини, я думаю, команды дали понять. для меня, я сталкиваюсь с этой проблемой, когда переустанавливаю postgresql, я пытаюсь перезапустить его по типу, service postgresql restart но он говорит, что у меня не было никакого кластера postgresql. Тогда я найду способ выручить меня :)
После трех часов поиска в Google вы, наконец, решили мою проблему. dpkg-reconfigure locales это чертовски важно.
Мне пришлось скомпилировать PostgreSQL 8.1 на Debian Squeeze, потому что я использую Project Open, который основан на OpenACS и не будет работать на более поздних версиях PostgreSQL.
Конфигурация компиляции по умолчанию помещает unix_socket в систему /tmp , но проект Open, который основывается на PostgreSQL, не будет работать , так как это выглядит для unix_socket на /var/run/postgresql .
Есть настройка, postgresql.conf чтобы установить местоположение сокета. Моя проблема заключалась в том, что либо я мог установить /tmp и psql работать, но не открыть проект, либо я мог установить его /var/run/postgresql и psql не работать, но открытие проекта сделало.
Одно из решений этой проблемы состоит в том, чтобы установить сокет для /var/run/postgresql и затем запустить psql , основываясь на предложении Питера, как:
Это выполняется локально с использованием локальных разрешений. Единственным недостатком является то, что он больше печатает, чем просто "psql".
В моем случае вместо:
и явно установить unix_socket /var/run/postgresql/.s.PGSQL.5432 в postgresql.conf .
Решение:
и это. ( 9.3 - это моя текущая версия PostgreSQL. Напишите свою версию!)
Если ваша служба Postgres запущена и работает без каких-либо ошибок или при запуске службы Postgres нет ошибок, но вы все еще получаете указанную ошибку, выполните следующие действия.
17.3.2. Проблемы с подключениями клиентов
Хотя ошибки подключений, возможные на стороне клиента, довольно разнообразны и зависят от приложений, всё же несколько проблем могут быть связаны непосредственно с тем, как был запущен сервер. Описание ошибок, отличных от описанных ниже, следует искать в документации соответствующего клиентского приложения.
19.3.1. Сбои при запуске сервера
не означает, что у вас закончилось место на диске. Это значит, что установленное в вашем ядре предельное число семафоров System V меньше, чем количество семафоров, которое пытается создать PostgreSQL . Как и в предыдущем случае можно попытаться обойти эту проблему, запустив сервер с меньшим числом допустимых подключений (max_connections), но в конце концов вам придётся увеличить этот предел в ядре.
Шаг 1: Запуск pg_lsclusters покажет все кластеры postgres, работающие на вашем устройстве
Скорее всего, статус будет ниже в вашем случае и сервис Postgres
Читайте также: