ポート5432でpostgresqlに接続できません
PostgreSQL 8.4を含む Bitnami Django stack をインストールしました。
psql -U postgresを実行すると、次のエラーが表示されます。
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"?
PGは間違いなく実行されており、pg_hba.confファイルは次のようになります。
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
Host all all 127.0.0.1/32 md5
# IPv6 local connections:
Host all all ::1/128 md5
何が得られますか？
pgが実行されていることの「証明」：
root@assaf-desktop:/home/assaf# ps axf | grep postgres
14338 ? S 0:00 /opt/djangostack-1.3-0/postgresql/bin/postgres -D /opt/djangostack-1.3-0/postgresql/data -p 5432
14347 ? Ss 0:00 \_ postgres: writer process
14348 ? Ss 0:00 \_ postgres: wal writer process
14349 ? Ss 0:00 \_ postgres: autovacuum launcher process
14350 ? Ss 0:00 \_ postgres: stats collector process
15139 pts/1 S+ 0:00 \_ grep --color=auto postgres
root@assaf-desktop:/home/assaf# netstat -nltp | grep 5432
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 14338/postgres
tcp6 0 0 ::1:5432 :::* LISTEN 14338/postgres
root@assaf-desktop:/home/assaf#
この問題は、バージョン番号なしでpostgresパッケージをインストールすることに起因します。 postgresがインストールされ、正しいバージョンになりますが、クラスターをセットアップするスクリプトは正しく実行されません。それはパッケージングの問題です。
postgresに慣れている場合は、このクラスターを作成してpostgresを実行するために実行できるスクリプトがあります。ただし、もっと簡単な方法があります。
最初に古いpostgresインストールをパージします。現在、問題は9.1にあるため、これがインストールされていると想定します
Sudo apt-get remove --purge postgresql-9.1
今、単に再インストール
Sudo apt-get install postgresql-9.1
パッケージ名とバージョン番号をメモします。 HTH。
このエラーメッセージはUnixドメインソケットに関するものなので、netstat呼び出しを調整して除外しないようにする必要があります。オプション-tなしで試してください：
netstat -nlp | grep 5432
サーバーは、クライアントが接続しようとしている/tmp/.s.PGSQL.5432ではなく、ソケット/var/run/postgresql/.s.PGSQL.5432を実際にリッスンしていると思います。 Unixドメインソケットディレクトリのソースのデフォルトは/tmpですが、Debianパッケージは/var/run/postgresqlに変更するため、これはDebianまたはUbuntuで手動またはサードパーティのPostgreSQLパッケージを使用する場合の典型的な問題です。 。
考えられる回避策：
- サードパーティのパッケージが提供するクライアントを使用します（
/opt/djangostack-1.3-0/postgresql/bin/psqlを呼び出します）。 Ubuntuが提供するパッケージを完全にアンインストールする可能性があります（他の逆依存関係のために困難になる場合があります）。 - サードパーティパッケージのソケットディレクトリをDebian/Ubuntuと互換性があるように修正します。
- 代わりに
-H localhostを使用して、TCP/IP経由で接続します。 -h /tmpまたは同等のPGHOST設定を使用して、正しいディレクトリを指すようにします。- サードパーティのパッケージを使用しないでください。
これは私のために働く：
編集：postgresql.conf
Sudo nano /etc/postgresql/9.3/main/postgresql.conf
有効化または追加：
listen_addresses = '*'
データベースエンジンを再起動します。
Sudo service postgresql restart
また、ファイルpg_hba.confを確認できます
Sudo nano /etc/postgresql/9.3/main/pg_hba.conf
ネットワークまたはホストアドレスを追加します。
Host all all 192.168.1.0/24 md5
psql -U postgres -h localhostを使用して、UNIXドメインソケットの代わりにTCPを介して接続を強制できます。 netstatの出力は、PostgreSQLサーバーがlocalhostのポート5432でリッスンしていることを示しています。
netstat の異なる呼び出しを使用して、PostgrSQLサーバーがどのローカルUNIXソケットを使用しているかを確認できます。
netstat -lp --protocol=unix | grep postgres
いずれにしても、PostgreSQLサーバーがリッスンするインターフェイスはpostgresql.confで設定されます。
このようなソフトリンクを作成するだけです：
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
これを行うことで動作させます：
dpkg-reconfigure locales
好みのロケールを選択して実行します
pg_createcluster 9.5 main --start
（9.5はpostgresqlの私のバージョンです）
/etc/init.d/postgresql start
そしてそれは動作します！
Sudo su - postgres
psql
OpenACSに基づいており、PostgreSQLの最新バージョンでは実行されないProject Openを使用しているため、Debian SqueezeでPostgreSQL 8.1をコンパイルする必要がありました。
デフォルトのコンパイル構成はunix_socketを/tmpに配置しますが、PostgreSQLに依存するProject Openはunix_socketで/var/run/postgresqlを探すため動作しません。
postgresql.confには、ソケットの場所を設定する設定があります。私の問題は、/tmpとpsqlを設定しても機能しているが、プロジェクトを開いていないか、/var/run/postgresqlとpsqlを設定してプロジェクトを開いているということです。した。
この問題の解決策の1つは、Peterの提案に基づいて、/var/run/postgresqlのソケットを設定し、psqlを実行することです。
psql -h /var/run/postgresql
これは、ローカルアクセス許可を使用してローカルで実行されます。唯一の欠点は、単に「psql」よりも入力が多いことです。
誰かが行ったもう1つの提案は、2つの場所の間にシンボリックリンクを作成することです。これも機能しましたが、再起動時にリンクが消えました。 -h引数を使用する方が簡単かもしれませんが、/etc/init.dのPostgreSQLスクリプト内からシンボリックリンクを作成しました。 「開始」セクションにシンボリックリンク作成コマンドを配置しました。もちろん、停止および開始または再起動コマンドを発行すると、既存のシンボリックリンクを再作成しようとしますが、警告メッセージ以外はおそらく害はありません。
私の場合、次の代わりに：
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
私は持っています
ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432
/var/run/postgresql/.s.PGSQL.5432でunix_socketをpostgresql.confに明示的に設定しています。
Postgresサービスがエラーなしで稼働している場合、またはPostgresサービスの開始時にエラーがなく、上記のエラーが引き続き発生する場合は、次の手順に従ってください
ステップ1：pg_lsclustersを実行すると、デバイスで実行されているすべてのpostgresクラスターが一覧表示されます
例えば：
Ver Cluster Port Status Owner Data directory Log file
9.6 main 5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
ほとんどの場合、ステータスはあなたのケースとpostgresサービスでダウンします
ステップ2：pg_ctlclusterを再起動します
#format is pg_ctlcluster <version> <cluster> <action>
Sudo pg_ctlcluster 9.6 main start
#restart postgres
Sudo service postgres restart
ステップ3：ステップ2が失敗し、エラーがスローされた
このプロセスが成功しない場合、エラーがスローされます。エラーログは/var/log/postgresql/postgresql-9.6-main.logで確認できます
私のエラーは：
FATAL: could not access private key file "/etc/ssl/private/ssl-cert-snakeoil.key": Permission denied
Try adding `postgres` user to the group `ssl-cert`
ステップ4：postgresの所有権を確認する
postgresが/var/lib/postgresql/version_no/mainの所有者であることを確認してください
そうでない場合は、実行します
Sudo chown postgres -R /var/lib/postgresql/9.6/main/
手順5：postgresユーザーがssl-certユーザーグループに属していることを確認する
ssl-certグループからPostgresユーザーを誤って削除したことが判明しました。以下のコードを実行して、ユーザーグループの問題を修正し、権限を修正します
#set user to group back with
Sudo gpasswd -a postgres ssl-cert
# Fix ownership and mode
Sudo chown root:ssl-cert /etc/ssl/private/ssl-cert-snakeoil.key
Sudo chmod 740 /etc/ssl/private/ssl-cert-snakeoil.key
# now postgresql starts! (and install command doesn't fail anymore)
Sudo service postgres restart
解決策：
これを行う
export LC_ALL="en_US.UTF-8"
この。 （9.は現在のPostgreSQLバージョンです。バージョンを書いてください！）
Sudo pg_createcluster 9.3 main --start
私はpostgres-9.5サーバーでこの問題を解決できませんでした。このサイトや他のサイトで修正の順列をすべて試行して3日間の進捗がなかった後、サーバーを再インストールし、5日間分の作業を失うことにしました。しかし、新しいインスタンスで問題を再現しました。これは、あなたが私がした破局的なアプローチをとる前に、それを修正する方法についてのいくつかの展望を提供するかもしれません。
まず、postgresql.confのすべてのログ設定を無効にします。これはセクションです：
# ERROR REPORTING AND LOGGING
そのセクションのすべてをコメント化します。次に、サービスを再起動します。
再起動するときは、/etc/init.d/postgresql startまたはrestartを使用します。再起動中にスーパーユーザーモードにすると便利です。その操作のためにXウィンドウを開いていました。 Sudo -iを使用して、スーパーユーザーモードを確立できます。
次の簡単なコマンドでサーバーに到達できることを確認します：psql -l -U postgres
それでも解決しない場合は、次のことを考慮してください。
解決策を見つけようとして、多くのフォルダーの所有権を変更していました。これらのフォルダの所有権とchmodsをあと2日間元に戻そうとしていることを知っていました。それらのフォルダーの所有権を既に台無しにしていて、サーバーを完全にパージしたくない場合は、影響を受けるすべてのフォルダーの設定の追跡を開始して、元の状態に戻します。別のシステムで並列インストールを実行し、すべてのフォルダーの所有権と設定を体系的に確認することをお勧めします。面倒ですが、データにアクセスできる場合があります。
アクセスできたら、# ERROR REPORTING AND LOGGINGファイルのpostgresql.confセクションの関連する各行を体系的に変更します。再起動してテストします。ログのデフォルトのフォルダーが失敗の原因であることがわかりました。 log_directoryを具体的にコメントアウトしました。システムがログをドロップするデフォルトのフォルダーは、/var/log/postgresqlです。
私の場合、/etc/postgresql/9.5/main/pg_hba.confの編集中にタイプミスをしたことが原因でした。
私が変更され：
# Database administrative login by Unix domain socket
local all postgres peer
に：
# Database administrative login by Unix domain socket
local all postgres MD5
ただし、MD5は小文字のmd5にする必要がありました。
# Database administrative login by Unix domain socket
local all postgres md5
私はFlaskを使用しているため、これは質問と正確には関連していませんが、これは私が得ていた正確なエラーであり、これはアイデアを得るための最も関連性の高いスレッドでした。
私のセットアップ：Windowsサブシステムfor Linux、Docker-compose w/makefile w/dockerfile、Flask、Postgresql（テーブルで構成されるスキーマを使用）
Postgresに接続するには、次のように接続文字列を設定します。
from flask import Flask
app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = "postgresql+psycopg2://<user>:<password>@<container_name_in_docker-compose.yml>/<database_name>"
注：このスレッドのメソッドを使用して動作するIP（localhost、127.0.0.1など）を取得したことはありません。 localhostの代わりにコンテナ名を使用するアイデアは、ここから来ました： https://github.com/docker-library/postgres/issues/297
スキーマを設定します。
from sqlalchemy import MetaData
db = SQLAlchemy(app, metadata=MetaData(schema="<schema_name>"))
セッションをセットアップするときに、関数の検索パスを設定します。
db.session.execute("SET search_path TO <schema_name>")
Postgresのアンインストールは納得がいかないようです。これは私の問題を解決するのに役立ちます：
Postgresサーバーを起動します。
Sudo systemctl start postgresqlサーバーが起動時に起動することを確認します。
Sudo systemctl enable postgresql
詳細情報はDigitalOceanサイトで見つけることができます ここ
/var/lib/postgresql/9.3/mainフォルダーのアクセス許可を変更したことが原因である可能性があります。
以下のコマンドを使用して、700に変更してみてください。
Sudo chmod 700 main
ピーター・アイゼントラウトが説明したのとまったく同じ問題がありました。 netstat -nlp | grep 5432コマンドを使用すると、サーバーがソケット/tmp/.s.PGSQL.5432をリッスンしていることがわかりました。
これを修正するには、postgresql.confファイルを編集して、次の行を変更します。
listen_addresses = '*'
unix_socket_directories = '/var/run/postgresql'
service postgresql-9.4 restart（9-4をご使用のバージョンに置き換えてください）を実行すると、リモート接続が機能するはずです。
ローカル接続を許可するには、/var/run/postgresqlディレクトリへのシンボリックリンクを作成するだけです。
ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432
pg_hba.confも正しく設定されていることを忘れないでください。
Run内にpostgresqlディレクトリを作成し、次のコマンドを実行します。
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
私の場合、私がしなければならないことはこれだけでした：
Sudo service postgresql restart
その後
Sudo -u postgres psql
これはうまくいきました。それが役に立てば幸い。乾杯:)。
何度も試行錯誤した結果、他の投稿に基づいて解決策を見つけました！
dpkg -l | grep postgres
apt-get --purge remove <package-founded-1> <package-founded-2>
whereis postgres
whereis postgresql
Sudo rm -rf <paths-founded>
Sudo userdel -f postgres
同じ問題を抱えながら、私は別のものを試しました：
手動でpostgresqlデーモンを起動しました：
FATAL: could not create shared memory segment ...
To reduce the request size (currently 57237504 bytes), reduce PostgreSQL's
shared memory usage, perhaps by reducing shared_buffers or max_connections.
そのため、私はshared_buffersおよびmax_connectionsの下限をpostgresql.confおよびrestartサービスに設定することでした。
これで問題は解決しました！
完全なエラーログは次のとおりです。
$ Sudo service postgresql start
* Starting PostgreSQL 9.1 database server * The PostgreSQL server failed to start. Please check the log output:
2013-06-26 15:05:11 CEST FATAL: could not create shared memory segment: Invalid argument
2013-06-26 15:05:11 CEST DETAIL: Failed system call was shmget(key=5432001, size=57237504, 03600).
2013-06-26 15:05:11 CEST HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 57237504 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration.
/ tmp unix_socket_directoriesを追加するだけです
postgresql.conf
unix_socket_directories = '/var/run/postgresql,/tmp'
ファイルを見つけます：
Sudo find /tmp/ -name .s.PGSQL.5432
結果：
/tmp/.s.PGSQL.5432
Postgresユーザーとしてログインします。
su postgres
psql -h /tmp/ yourdatabase
同じ問題がありました（Ubuntu 15.10（wily））。 Sudo find / -name 'pg_hba.conf' -printまたはSudo find / -name 'postgresql.conf' -printが空になりました。それ以前は、postgresqlの複数のインスタンスがインストールされているようでした。
あなたがインストールされている、または依存関係の問題のリストを表示すると似ているかもしれません
.../postgresql
.../postgresql-9.x
等々。
その場合、各パッケージを1つずつSudo apt-get autoremoveする必要があります。
その後、これに従って手紙を送れば、問題ありません。特にキーのインポートとソースリストへの追加に関しては
Sudo apt-get update && Sudo apt-get -y install python-software-properties && wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | Sudo apt-key add -
Wilyを使用しない場合は、wilyをご使用のリリース、つまりlsb_release -csの出力に置き換えてください
Sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ wily-pgdg main" >> /etc/apt/sources.list.d/postgresql.list'
Sudo apt-get update && Sudo apt-get install postgresql-9.3 pgadmin3
そして、あなたは問題なく、接続してユーザーを作成できるはずです。
期待される出力：
Creating new cluster 9.3/main ...
config /etc/postgresql/9.3/main
data /var/lib/postgresql/9.3/main
locale en_US.UTF-8
socket /var/run/postgresql
port 5432