Postgresql сервер не запускается

[Ubuntu 16.04] Я установил postgresql 9.5 вместе с зависимостями:

sudo sh -c "echo 'deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main' > /etc/apt/sources.list.d/pgdg.list"
wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install postgresql-common
sudo apt-get install postgresql-9.5 libpq-dev

Когда я хочу бежать, psqlя получаю:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Но /var/run/postgresql/пусто. Когда я перезапускаю posgresql, все выглядит нормально:

$ /etc/init.d/postgresql restart
[ ok ] Restarting postgresql (via systemctl): postgresql.service.

$ /etc/init.d/postgresql status
● postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
   Active: active (exited) since wto 2016-09-27 16:18:26 CEST; 1min 15s ago
  Process: 3076 ExecReload=/bin/true (code=exited, status=0/SUCCESS)
  Process: 3523 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 3523 (code=exited, status=0/SUCCESS)

но если проверить ps auxесть не такой PID (почему ??)

Полная переустановка вообще не помогает. Как я могу это исправить?

Это особенность интеграции systemd PostgreSQL в Xenial.

Служебный модуль postgresql, установленный пакетом postgresql-common, является всего лишь фиктивной службой, которая заставляет фактическую службу postgresql@9.6-main запускаться через зависимость. Вы можете увидеть эту зависимость, выполнив команду

systemctl list-dependencies postgresql

Эта зависимость не является постоянной, но генерируется во время загрузки системы генератором systemd, /lib/systemd/system-generators/postgresql-generatorкоторый также поставляется с пакетом postgresql-common. Проверяет генератор ли режим запуска в файле /etc/postgresql/9.6/main/start.confустановлен на auto, и если да, то устанавливает зависимость , которая впоследствии приводит пример 9,6-главный должен быть запущен.

(Точнее, он проверяет все подкаталоги конфигурации /etc/postgresql/*/*и создает зависимости для всех экземпляров, которые настроены для автоматического запуска, но при установке по умолчанию будет только один экземпляр.)

Из-за ограничений генераторов systemd (см. man systemd.generator) Этот процесс может завершиться неудачей, что приведет к отсутствию зависимостей после перезагрузки. Затем Systemd запустит только фиктивный сервис

systemd[1]: Starting PostgreSQL RDBMS...
systemd[1]: Started PostgreSQL RDBMS.

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

systemctl start postgresql

будет просто воспроизвести этот результат. Выполнение команды

systemctl daemon-reload

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

Чтобы окончательно решить проблему, вам нужно найти причину сбоя генератора во время загрузки. Возможные причины можно найти на странице man systemd.generator. В моем случае это был файл конфигурации PostgreSQL, /etc/postgresql/9.6/main/postgresql.confкоторый был связан с другой файловой системой, которая еще не была доступна, когда генератор запускался рано во время загрузки. postgresql-generatorпроверяет существование этого файла, хотя в противном случае он не нужен.

Обращаясь к ответу Тилмана, но недостаточно Kudos, чтобы комментировать ...

Если вам не требуется, чтобы служба называлась postgresql, и вам не нужны службы-пустышки, она должна работать только для непосредственного управления реальной службой. Это имя: postgresql@$version-$cluster.service В вашем случае это должно быть коротко postgresql-9.5-main . Хотел бы начать

systemctl start postgresql@9.5-main

и остановиться

systemctl stop postgresql@9.5-main

Статус также даст вам гораздо лучшую и точную информацию, чем на автоматически сгенерированной службе оболочки.

systemctl status postgresql@9.5-main

Для 9.6 это выглядит так:

● postgresql@9.6-main.service - PostgreSQL Cluster 9.6-main
   Loaded: loaded (/lib/systemd/system/postgresql@.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-09-13 00:41:50 CEST; 7h ago
  Process: 10235 ExecStop=/usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast %i stop (code=exited, status=2)
  Process: 10676 ExecStart=postgresql@%i --skip-systemctl-redirect %i start (code=exited, status=0/SUCCESS)
 Main PID: 10683 (postgres)
   CGroup: /system.slice/system-postgresql.slice/postgresql@9.6-main.service
           ├─10683 /usr/lib/postgresql/9.6/bin/postgres -D /var/lib/postgresql/9.6/main -c config_file=/etc/postgresql/9.6/main/postgresql.conf
           ├─10685 postgres: 9.6/main: checkpointer process
           ├─10686 postgres: 9.6/main: writer process
           ├─10748 postgres: 9.6/main: wal writer process
           ├─10749 postgres: 9.6/main: autovacuum launcher process
           ├─10750 postgres: 9.6/main: archiver process   last was 000000020000000000000082
           ├─10751 postgres: 9.6/main: stats collector process

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

Я нашел решение в этом ответе dba.stackexchange.com :

1. Используйте sudo dpkg-reconfigure localesдля генерации необходимых локалей
2. Удалите существующий кластер базы данных через sudo pg_dropcluster 9.5 main(это сотрет все данные в кластере!)
3. Пересоздать кластер через sudo pg_createcluster 9.5 main --start
4. Перезапустите PostgreSQL через sudo service postgresql restart

Было бы лучше использовать сценарии запуска systemd с Ubuntu 16.04, сценарии инициализации могут работать некорректно. Postgres 9.5 уже есть в репозиториях Ubuntu, поэтому попробуйте вместо этого запустить systemd.

Еще один "укушен этим".

pg_upgradeclusterФактически покинул целевую версию (9.6) в «ручном режиме» на порту 5433 и версии исходного (9.5) в порту 5432.

Даже после pg_dropcluster 9.5. Редактирование файла start.conf не помогло, но намекнуло об этом systemctl daemon-reload, поскольку на основе этого файла конфигурации генератор решает, использовать ли символическую ссылку для служебного файла:

for conf in /etc/postgresql/*/*/postgresql.conf; do
    # trimmed for brevity
    [ "$start" = "auto" ] || continue
    ln -s "$pgservice" "$wantdir/postgresql@$version-$cluster.service"
done

Поэтому, если в кластере, который вы хотите запустить, нет слова «auto» в файле start.conf, вам необходимо выполнить перезагрузку системы (или перезагрузить компьютер), чтобы включить его во время загрузки.

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

Я отключил волшебный «супер сервис» вот так:

root@server# systemctl disable postgresql

Затем я активировал конкретный сервис:

root@server:~# systemctl enable postgresql@9.5-main.service 

После перезагрузки все снова заработало.

Была такая же ошибка, потраченные впустую часы, простое решение. Проверьте этот ТАК вопрос и мой ответ, который:

sudo service postgresql restart

У меня была эта проблема из-за другой причины: права доступа к каталогу. У меня был полный цикл CHMOD, как это:

chmod -R 644 /etc/postgresql/10/main

Это устанавливает каталог как неисполняемый, что предотвращает его чтение postgres.

У меня была такая же проблема при проверке найденной проблемы с разрешением ssl-cert-snakeoil.key.

Установить право собственности

chown root: ssl-cert ssl-cert-snakeoil.key chmod 640 ssl-cert-snakeoil.key

и сделал чистый перезапуск.