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がないことを確認した場合（なぜ??）

完全な再インストールはまったく役に立ちません。どうすれば修正できますか？

これは、XenialでのPostgreSQLのsystemd統合の特異性です。

postgresql-commonパッケージによってインストールされるpostgresqlサービスユニットは、実際のサービスpostgresql@9.6-mainが依存関係を介して開始されるようにする単なるダミーサービスです。コマンドを実行すると、その依存関係を確認できます

systemctl list-dependencies postgresql

その依存関係は永続的ではありませんが/lib/systemd/system-generators/postgresql-generator、postgresql-commonパッケージに付属しているsystemdジェネレーターによってシステムのブート中に生成されます。ジェネレーターは、ファイルのスタートアップモード/etc/postgresql/9.6/main/start.confがに設定されているかどうかを確認しauto、設定されている場合は、インスタンス9.6-mainを開始する依存関係を設定します。

（より正確には、すべての構成サブディレクトリ/etc/postgresql/*/*をチェックし、自動起動用に構成されたすべてのインスタンスの依存関係を作成しますが、デフォルトのインストールでは1つのインスタンスのみになります。）

systemdジェネレーターの制限により（を参照man systemd.generator）、このプロセスは失敗し、リブート後に依​​存関係がなくなる場合があります。Systemdはダミーサービスのみを開始し、書き込みます

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

ログに記録しますが、それ以外は何もしません。手動でサービスを開始しようとしています

systemctl start postgresql

その結果を再現するだけです。コマンドを実行する

systemctl daemon-reload

rootがジェネレーターを再実行し、ほとんどの場合、次のリブートまで問題を修正するため、手動で。

問題を永続的に解決するには、起動中にジェネレーターが失敗する理由を見つける必要があります。考えられる原因は、systemd.generatorのマンページに記載されています。私の場合、/etc/postgresql/9.6/main/postgresql.conf起動中にジェネレータが実行されたときにまだ利用可能ではなかった別のファイルシステムにシンボリックリンクされたPostgreSQL構成ファイルでした。postgresql-generator必要ない場合でも、そのファイルの存在を確認します。

ティルマンの答えを拡張しますが、コメントするには賞賛が足りません...

サービスを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で使用することをお勧めします。最近では、initスクリプトが適切に動作しない場合があります。Postgres 9.5はすでにubuntuリポジトリにあるので、代わりに試してみてください。systemdの起動が必要です。

別の「これに噛まれた」。

pg_upgradecluster実際にポート5432でポート5433およびソースバージョン（9.5）の「マニュアル」モードのターゲットバージョン（9.6）を残しました。

後でも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に「auto」という単語がない場合は、システムのリロード（または再起動）を実行して、起動時に有効にする必要があります。

リブートでこれを確認する必要がありますが、上記の問題がかなり自信があると考えられます。

このような魔法の「スーパーサービス」を無効にしました。

root@server# systemctl disable postgresql

次に、具体的なサービスをアクティブにしました。

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

再起動後、すべてが再び機能しました。

同じエラー、無駄な時間、簡単な解決策がありました。このSOの質問と私の答えを確認してください：

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

そして、クリーンな再起動を行いました。