Почему закрылось соединение postgresql ubuntu

Обновлено: 03.07.2024

То, что там происходит? Любой указатель будет высоко ценится.

Изменить: что еще хуже, PostgreSQL 10 является единственным перечисленным пакетом в Ubuntu 18.04, нет очевидного "подходящего" способа установки более старой версии PostgreSQL

Из apt list --installed вас фактически не установлен сервер PostgreSQL 10.

Отсутствие ошибки systemctl и тот факт, что сервис postgresql существует, сбивают с толку: это потому, что postgresql - это "зонтичный" сервис, который запускает каждый экземпляр postgresql, установленный и настроенный. В вашем случае у вас в настоящий момент нет такого экземпляра, но это нормально, если речь идет о сервисе postgresql . В наиболее общем случае у вас может быть несколько разных версий PostgreSQL, работающих одновременно (из разных пакетов postgresql-<version> ), а также несколько экземпляров одной и той же версии (из одного пакета).

Я бы посоветовал проверять ваши экземпляры PostgreSQL с помощью pg_lsclusters а не systemctl . Смотрите также pg_ctlcluster для управления ими.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Это для postgresql 10 и Ubuntu 18.04, и может работать или не работать для других версий. PS: Если вы в последнее время вмешивались в языковые настройки, пожалуйста, скажите мне, потому что может быть связь с ошибкой postgres

Вчера у меня возникла точно такая же проблема, и никто во всем Интернете не мог мне помочь, поэтому я стал мошенником . И это сработало!

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

Теперь перейдем к реальным шагам (это именно то, что я сделал, шаги между [ ] вы можете пропустить):

Теперь убедитесь, что у вас есть эта строка в /etc/apt/sources.list

Если нет, просто добавьте это . Давай продолжим:

Если что-то из этого не существует, я не могу вам помочь. Вы также должны убедиться, что пользователь postgres существует. Давайте продолжим:

Теперь перейдите в файл /etc/environment и добавьте его в PATH: /usr/lib/postgresql/10/bin

Создайте /var/lib/postgresql/.bashrc и запишите это

А теперь финальная часть:

Для запуска postgresql:

Чтобы закончить это:

Базовая конфигурация (введите интерпретатор postgresql ):

ЭКСТРА: МЕТАСПЛОЙТ

Кроме того, если у вас возникнут проблемы с установочной частью пакета ruby , эта команда может спасти вам жизнь: gem pristine --all

Я использовал sudo netstat -nlp | grep 5432 , чтобы увидеть статус, но ничего не показалось. И я поискал в Интернете, кто-то сказал мне изменить pg_hba.conf , но я не могу locate этот файл. И я тоже пробовал эту команду sudo ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432 . Не может работать.

22 ответа

Шаг 1. Убедитесь, что база данных работает

Команда может отличаться в зависимости от вашей операционной системы. Но в большинстве систем * ix будет работать следующее: он будет искать postgres среди всех запущенных процессов

В моей системе Mac OSX это выплевывает

Последний столбец показывает команду, используемую для запуска сервера, и параметры.

Вы можете просмотреть все варианты, доступные для запуска сервера postgres, используя следующее.

Оттуда вы увидите, что варианты -D и -r - это соответственно datadir и logfilename .

Шаг 2. Если служба postgres запущена

Используйте find для поиска местоположения сокета, который должен быть где-нибудь в /tmp

Если postgres запущен и принимает подключения к сокету, приведенное выше должно сообщить вам местоположение сокета. На моей машине это оказалось:

Затем попробуйте подключиться через psql, явно указав расположение этого файла, например.

Шаг 3. Если служба запущена, но вы не видите сокет

Если вы не можете найти сокет, но видите, что служба запущена, убедитесь, что в файле pg_hba.conf разрешены локальные сокеты.

Перейдите к datadir , и вы должны найти файл pg_hba.conf .

По умолчанию в нижней части файла вы должны увидеть следующие строки:

Если вы его не видите, вы можете изменить файл и перезапустить службу postgres.

В моем случае я увидел эту ошибку, и postgres не запущен.

Проблема заключалась в том, что при установке не удалось создать требуемый кластер.

Решением было создать папку /etc/postgres//main

А затем создайте кластер с помощью:

После этого, просто перезапустив службу postgresql, все должно работать.

У меня возникла эта проблема при работе с PostgreSQL в Ubuntu 18.04.

Я проверил свой статус PostgreSQL и понял, что он работает нормально, используя:

Я также попытался перезапустить сервер PotgreSQL на машине, используя:

Но проблема не исчезла:

После ответа Noushad я сделал следующее :

Перечислите все кластеры Postgres, запущенные на вашем устройстве:

Это дало мне этот вывод красного цвета, показывая, что все они не работают, а статус также показывает не работает :

Перезапустите pg_ctlcluster для одного из кластеров серверов. Для меня я перезапустил PG 10 :

Однако он вызвал ошибку ниже, и та же ошибка возникла, когда я попытался перезапустить другие кластеры PG:

Проверьте журнал на наличие ошибок, в данном случае мой - PG 10 :

Я увидел следующую ошибку:

Это было вызвано тем, что я внес изменения в права доступа к файлам для каталога данных PostgreSQL.

Я исправил это, выполнив команду ниже. Я выполнил команду для 3 кластеров PG на своей машине:

После чего я перезапустил каждый из кластеров PG:

И вот, наконец, я снова проверил работоспособность кластеров:

На этот раз все снова было хорошо, так как статус показал онлайн :

Надеюсь, это поможет

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

Оказывается, всякий раз, когда вы используете синтаксис ALTER SYSTEM SET . , PostgreSQL записывает в файл с именем postgresql.auto.conf . Этот файл читается в дополнение к обычным файлам postgresql.conf и pg_hba.conf . В моем дистрибутиве Ubuntu (18.04) они находятся в разных папках (!):
- pg_hba.conf и postgresql.conf оба находятся в /etc/postgresql/12/main
- Автоматически созданный файл: /var/lib/postgresql/12/main/postgresql.auto.conf

Я пытался изменить конфигурацию с помощью ALTER SYSTEM SET listen_addresses = <my-ip> , но допустил ошибку, в результате чего возникла некорректная конфигурация «призрак», которую я не смог найти. Как только я стер оскорбительную строку в postgresql.auto.conf , он все исправил.

Я мог бы решить эту проблему, установив правильные разрешения для datadir. Так должно быть

Убедитесь, что Postgres работает, используя:

Проверьте каталог данных и postgresql.conf .

В моем случае каталог данных в -D отличался от каталога в postgresql.conf

Итак, я изменил каталог данных в postgresql.conf , и это сработало.

У меня была аналогичная проблема, и проблема была в файле конфигурации pg_hba.conf. Ранее я внес некоторые изменения, из-за которых сервер отказывался от ошибок при попытке его запуска. Комментирование лишних дополнений решило проблему.

У меня такая же проблема. Вроде нет сокета, когда нет кластера.

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

Это может вызвать что угодно, например, моя проблема была вызвана опечаткой в ​​файлах конфигурации. Некоторые люди говорят, что это вызвано файлами сертификатов, другая группа считает, что причиной этого являются несогласованные местные жители.

Если вы не можете найти решение своей проблемы, удалите postgres и переустановите его. Это лучшее решение.

Во время новой установки postgresql. По умолчанию имя пользователя и пароль назначаются как «postgres». Эта СУБД предоставляет возможность добавить роль для нового пользователя и создать базу данных. Если вы получаете такие ошибки:

логин по умолчанию логин:

ype psql для интерактивной подсказки

Чтобы выйти из режима быстрого использования

Чтобы создать новую роль пользователя

Теперь вы находитесь в интерактивной оболочке psql. Наслаждаться. Не забудьте войти под своим именем пользователя и ввести psql для оболочки.

Итак, для меня и моих друзей, работающих над приложением Node.js (с Postgres и Sequelize), нам пришлось

brew services start postgresql **** (используйте Homebrew для запуска postgres)

createdb <name of database in config.json file>

Просто хочу сделать небольшое дополнение: если ваш экземпляр жалуется на сокет, вы также можете проверить unix_socket_directories в файле /data/postgresql.conf , который мог быть установлен в /tmp , например, если вы использовали сторонний дистрибутив. Вы можете изменить его на /var/run/postgresql и перезапустить службу. Для этого также может потребоваться создать каталог postgresql в /var/run и subsys/postgresql-9.6 в /var/lock , если они еще не существуют (работало для меня с postgresql 9.6).

Ошибка означает, что сервер Postgres не запущен. Попробуйте запустить его:

Убедитесь, что сервер запускается при загрузке:

Краткое руководство по debian для удаленного доступа к базе данных postgres на сервере из клиента psql: (измененная конфигурация документирована в файлах):

sudo /etc/init.d/postgresql restart изменения вступают в силу

войдите со стороны клиента с помощью psql --host=ipofserver --port=5432 --username=remoteuser --password --dbname=mydb

Я решил эту проблему, проверив свою файловую систему, диск был полностью заполнен, поэтому база данных не запускалась

Подключения к сокету домена Unix "/var/run/postgresql/.s.PGSQL.5432" ?

Я пробовал несколько способов устранения неполадок, пока не проверил использование своего диска и не обнаружил, что он заполнен, используется 100%,

Решено! Хотя я не знаю, что случилось, но я просто удалил все и переустановил. Это команда, которую я использовал, чтобы удалить sudo apt-get --purge remove postgresql\* и dpkg -l | grep postgres . Последний - найти все пакеты, если он не чистый.

Я столкнулся с той же проблемой и

Это сработало для меня.

Пару раз сталкивался с подобной проблемой. Обычно я просто выполняю новую установку PostgreSQL, следуя этому tutorial, и это решает проблему за счет потери данных.

Я был полон решимости получить настоящее исправление сегодня. Перезапуск PostgreSQL разрешил это на ubuntu. sudo /etc/init.d/postgresql restart

Если при запуске службы Postgres ошибок нет, выполните следующие действия.

Шаг 1. Запуск pg_lsclusters отобразит список всех кластеров Postgres, работающих на вашем устройстве.

Скорее всего, в вашем случае статус будет понижен. Если нет, перезапустите службу PostgreSQL

Шаг 2: перезапустите pg_ctlcluster

Шаг 3. Шаг 2 завершился неудачно, и возникла ошибка

Если перезапуск pg_lsclusters не был успешным, он выдаст ошибку. Моя ошибка была (вы можете увидеть ошибки в журналах /var/log/postgresql/postgresql-9.6-main.log )

Шаг 4: проверьте право собственности на postgres

Убедитесь, что postgres является владельцем /var/lib/postgresql/version_no/main например: sudo chown postgres -R /var/lib/postgresql/9.6/main/

Шаг 5. Убедитесь, что пользователь postgres принадлежит к группе пользователей ssl-cert.

Я установил стек Bitnami Django, который включал PostgreSQL 8.4.

При запуске psql -U postgres я получаю следующую ошибку:

PG определенно работает, и pg_hba.conf файл выглядит так:

«Доказательство», что pg работает:

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

Эта проблема возникает из-за установки postgres пакета без номера версии. Хотя postgres будет установлен и будет правильной версии, скрипт для настройки кластера не будет работать правильно; это проблема упаковки.

Если вам удобно, postgres есть скрипт, который вы можете запустить, чтобы создать этот кластер и postgres запустить его. Тем не менее, есть более простой способ.

Сначала удалите старую установку postgres. В настоящее время проблема заключается в 9.1, поэтому я буду считать, что это то, что вы установили

Теперь просто переустановите

Запишите название пакета с номером версии. НТН.

Это должен быть принятый ответ, работает также с postgres 9.4 / ubuntu 14.10 Этот ответ помог мне с путаницей Postgres 9,4 и 9,3. Здорово. Работал для Ubuntu 16.04 и Postgres 9.5, но сначала должен был удалить каждый пакет, связанный с Postgres. Это действительно потрясающий ответ! А также ужасный пользовательский опыт на стороне 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. благодарю вас! Боже мой . наконец то, что сработало - ничего больше не сработало, пока я не добавил адрес и не прокомментировал адрес для прослушивания. Я могу подтвердить , что он работает на Ubuntu командной сервера Баш на ОС Windows 10.

Вы можете использовать, psql -U postgres -h localhost чтобы заставить соединение происходить по TCP вместо доменных сокетов UNIX; ваш netstat вывод показывает, что сервер PostgreSQL прослушивает порт 5432 локального хоста.

Вы можете узнать, какой локальный сокет UNIX используется сервером PostgrSQL, используя другой вызов netstat :

В любом случае, интерфейсы, на которых слушает сервер PostgreSQL, настроены в postgresql.conf .

Просто создайте мягкую ссылку, подобную этой:

Это сработало для меня и, казалось, было самым простым решением без изменения конфигурации postgresql. Будьте уверены, что вы являетесь суперпользователем при попытке сделать ссылку. ln: не удалось создать символическую ссылку '/var/run/postgresql/.s.PGSQL.5432': файл существует Я создал папку "postgresql" в каталоге / var / run /. Этого не было.

Я заставляю это работать этим:

Выберите предпочитаемые локали и запустите

(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 нет ошибок, но вы все еще получаете указанную ошибку, выполните следующие действия.

Шаг 1: Запуск pg_lsclusters покажет все кластеры postgres, работающие на вашем устройстве

Скорее всего, статус будет ниже в вашем случае и сервис Postgres

Шаг 2: перезапустите pg_ctlcluster

Шаг 3: Шаг 2 не удался и выдал ошибку

Если этот процесс не будет успешным, он выдаст ошибку. Вы можете увидеть журнал ошибок на /var/log/postgresql/postgresql-9.6-main.log

Моя ошибка была:

Шаг 4: проверьте право собственности на postgres

Убедитесь, что postgres это владелец /var/lib/postgresql/version_no/main

Если нет, запустите

Шаг 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 два дня. Если вы уже перепутали владельцев этих папок и не хотите полностью очищать свой сервер, начните отслеживать настройки всех затронутых папок, чтобы вернуть их в исходное состояние. Возможно, вы захотите попробовать выполнить параллельную установку в другой системе и систематически проверять владение и настройки всех папок. Утомительно, но вы можете получить доступ к своим данным.

Я установил стек Bitnami Django, который включал PostgreSQL 8.4.

Когда я бегу psql -U postgres Я получаю следующую ошибку:

PG определенно работает и pg_hba.conf файл выглядит так:

"Доказательство", что pg работает:

21 ответ

Эта проблема возникает из-за установки postgres пакет без номера версии. Хотя postgres будет установлена ​​и будет правильной версией, скрипт для настройки кластера будет работать некорректно; это проблема упаковки.

Если вам удобно postgres есть скрипт, который вы можете запустить, чтобы создать этот кластер и получить postgres Бег. Тем не менее, есть более простой способ.

Сначала удалите старую установку postgres. В настоящее время проблема заключается в 9.1, поэтому я буду считать, что это то, что вы установили

Теперь просто переустановите

Запишите название пакета с номером версии. НТН.

The error message refers to a Unix-domain socket, so you need to tweak your netstat invocation to not exclude them. So try it without the option -t :

I would guess that the server is actually listening on the socket /tmp/.s.PGSQL.5432 rather than the /var/run/postgresql/.s.PGSQL.5432 that your client is attempting to connect to. This is a typical problem when using hand-compiled or third-party PostgreSQL packages on Debian or Ubuntu, because the source default for the Unix-domain socket directory is /tmp but the Debian packaging changes it to /var/run/postgresql ,

Возможные обходные пути:

  • Use the clients supplied by your third-party package (call /opt/djangostack-1.3-0/postgresql/bin/psql ). Возможно, удалите все пакеты, поставляемые с Ubuntu (это может быть сложно из-за других обратных зависимостей).
  • Исправьте каталог сокетов стороннего пакета, чтобы он был совместим с Debian/Ubuntu.
  • использование -H localhost to connect via TCP/IP instead.
  • использование -h /tmp or equivalent PGHOST setting to point to the right directory.
  • Не используйте сторонние пакеты.

Ты можешь использовать psql -U postgres -h localhost заставить соединение происходить через TCP вместо доменных сокетов UNIX; ваш netstat вывод показывает, что сервер PostgreSQL прослушивает порт 5432 локального хоста.

Вы можете узнать, какой локальный сокет UNIX используется сервером PostgrSQL, используя другой вызов netstat:

В любом случае, интерфейсы, на которых слушает сервер PostgreSQL, настроены в postgresql.conf ,

Просто создайте мягкую ссылку, подобную этой:

Это работает для меня:

Включить или добавить:

Перезапустите ядро ​​базы данных:

Также вы можете проверить файл pg_hba.conf

И добавьте адрес своей сети или хоста:

Я заставляю это работать этим:

Выберите предпочитаемые локали и запустите

(9.5 - это моя версия postgresql)

и тогда это работает!

Мне пришлось скомпилировать PostgreSQL 8.1 на Debian Squeeze, потому что я использую Project Open, который основан на OpenACS и не будет работать на более поздних версиях PostgreSQL.

Конфигурация компиляции по умолчанию помещает unix_socket в /tmp , но Project 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 ,

Если ваша служба Postgres запущена и работает без каких-либо ошибок или при запуске службы Postgres нет ошибок, но вы все еще получаете указанную ошибку, выполните следующие действия.

Шаг 1: Бег pg_lsclusters выведет список всех кластеров postgres, работающих на вашем устройстве

Скорее всего, статус будет ниже в вашем случае и сервис Postgres

Шаг 2: перезапустите pg_ctlcluster

Шаг 3: Шаг 2 не удался и выдал ошибку

Если этот процесс не будет успешным, он выдаст ошибку. Вы можете увидеть журнал ошибок на /var/log/postgresql/postgresql-9.6-main.log

Моя ошибка была:

Шаг 4: проверьте право собственности на postgres

Удостоверься что postgres является владельцем /var/lib/postgresql/version_no/main

Если нет, запустите

Шаг 5: Проверьте, что пользователь postgres принадлежит к группе пользователей ssl-cert

Решение:

и это. (9.3 - это моя текущая версия PostgreSQL. Напишите свою версию!)

В моем случае это было вызвано опечаткой, которую я сделал при редактировании /etc/postgresql/9.5/main/pg_hba.conf

Но MD5 должен был быть в нижнем регистре md5 :

Во-первых, отключите все параметры ведения журнала в postgresql.conf. Это раздел:

Закомментируйте все в этом разделе. Затем перезапустите сервис.

При перезапуске используйте /etc/init.d/postgresql start или же restart Я нашел полезным находиться в режиме суперпользователя при перезапуске. У меня было открыто окно x только для этой операции. Вы можете установить этот режим суперпользователя с помощью sudo -i ,

Убедитесь, что к серверу можно подключиться с помощью этой простой команды: psql -l -U postgres

Если это не помогает, то подумайте:

Я менял владельца многих папок, пытаясь найти решение. Я знал, что я, вероятно, буду пытаться вернуть владельцы этих папок и chmod еще 2 дня. Если вы уже перепутали владельцев этих папок и не хотите полностью очищать свой сервер, начните отслеживать настройки всех затронутых папок, чтобы вернуть их в исходное состояние. Возможно, вы захотите попробовать выполнить параллельную установку в другой системе и систематически проверять владение и настройки всех папок. Утомительно, но вы можете получить доступ к своим данным.

Знаю, что уже замылили эту тему, но все, что я нашел не помогло или не соответствует моей ситуации, так что прошу помощи знатоков.

опять пусто и в логах пусто. во всех, что я смог найти..

при запуске ошибок не выдает но и не запускается.. как так? при этом

Но и в HTOP процесса с PID 11432 нету. я ничего не понимаю

Active: active (exited) since Wed 2017-11-08 10:32:43 MSK; 26min ago

а чуть подробнее??

could not connect to server: Connection refused

А ты роли добавил?

Dron ★★★★★ ( 08.11.17 11:19:16 )
Последнее исправление: Dron 08.11.17 11:25:24 (всего исправлений: 1)

Что тебе нужно подробнее? здесь и так все ясно написано

ну, видимо, мне не ясно, раз я спрашиваю. Логично же.

я не понимаю, что ему нужно от меня?

postgresql.service - запускает все настроенные инстансы постгреса в убунте, для того чтобы запустить нужный нужно стартовать postgresql-<версия_постреса>.service.

Deleted ( 08.11.17 11:34:13 )
Последнее исправление: MyLittleLoli 08.11.17 11:36:15 (всего исправлений: 1)

createuser --interactive сделай, добавь пользователя дай ему нужную роль, зайди от него.

В соединении отказано, всё работает, просто у тебя нет доступа

ну, видимо, мне не ясно, раз я спрашиваю. Логично же.

Ну, кроме вчитаться в текст я тебе больше ничего предложить не могу

В соединении отказано, всё работает, просто у тебя нет доступа

Это не значит, что нет доступа, это значит, что там попросту некому это соединение принимать.


вот жесть-то, и советчики такие же.

Я и говорю что ролей нет

Ну так насоветуй )

Ты бы внимательно прочитал на что отвечаешь.

Там не то, что ролей, там и самого процесса постгресса нет

Что в pgstartup.log?

мне не добавить роль

Тьфу блин, ай нуу, пойду кофе пить и просыпаться :D

у меня такого нет


Значит есть /var/lib/postgresql/версия/pg_log/*.log

Покажи systemctl list-units|grep postgres

Там должен быть сервис вида postgresql@9.5-main.service. Вот его и запускаешь, systemctl start postgresql@9.5-main.service.

Если нет, то смотришь в /var/lib/postgres, есть ли там что-нибудь. Если там пусто, значит у тебя нет базы, и ее нужно создать.

Точно нет? Показывай /etc/init.d/postgresql — посмотрим, что там в убунтушном инит-скрипте накручено.

Какой инит-скрипт, у него systemd.

У убунты логи постгреса в /var/log/postgresql. Смотри почему он фейлится. Ну и можешь journalctl -e -u postgresql@9.5-main.service глянуть.

Deleted ( 08.11.17 12:44:08 )
Последнее исправление: MyLittleLoli 08.11.17 12:45:16 (всего исправлений: 1)

смотри во время запуска/перезапуска сервиса
tail -F /var/log/syslog

)) А анон в теме, да. Или шарит по английски ;)

я не понимаю, что ему нужно от меня?

Он должен (psql) через чёта общаться. SocketЫ там, порты всякие.


Эти команды что пишут?

в логе ппусто, а в журнале:

В конфиге что-нибудь менял?

Попробуй запустить так

И после этого в логах ничего нет?

Место-то на сервер есть? df -h что показывает?

серьезно нет места.

это не нормально.

да действительно проблема была в свободном месте.

Спасибо всем за помощь!

- если после старта ОС немного подождать и просто перезапустить демон postgresql (service postgresql stop/start), то проблема уходит. Правда, не всегда после первого рестарта. Иногда нужно несколько раз перезапустить демон.

Никогда раньше такого не видел. Куда копать ума не приложу. Перерыл интернет, - наткнулся сюда. Хэлп.

Читайте также: