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

Расширение на ответе Tilman, но недостаточно Благодарности комментарию...

, Если Вам не нужен сервис, который назовут 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 с человечностью 16.04, init сценарии не мог бы работать правильно в эти дни. Пост-ГРЭС 9.5 уже находится в человечности repos так попытка, что вместо этого, она должна иметь запуск 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

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

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

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

sudo service postgresql restart

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

root@server# systemctl disable postgresql

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

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

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

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

Владение Набора

показанный root:ssl-сертификат ssl-cert-snakeoil.key chmod 640 ssl-cert-snakeoil.key

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

Это - особенность systemd интеграции PostgreSQL в Гостеприимном.

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

systemctl list-dependencies postgresql

Та зависимость не является постоянной, но сгенерированная во время начальной загрузки системы systemd генератором /lib/systemd/system-generators/postgresql-generator который также идет с postgresql-общим пакетом. Генератор проверяет ли режим запуска в файл /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

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

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

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

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

Это устанавливает каталог как неисполняемый файл, который препятствует тому, чтобы пост-ГРЭС читала его.

Это также может произойти, если есть проблема, препятствующая запуску фактической службы Postgresql@$VERSION-main. Перезапуск покажет, что postgresql.service быстро запускается, но затем закрывается.

Мне удалось запустить реальную службу с помощью sudo service postgresql@12-main start, чтобы увидеть, что произошла ошибка, а затем использовать journalctl -xe для просмотра журналов и диагностировать проблему (это была синтаксическая ошибка в файле конфигурации...)