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
サーバーは、クライアントが接続しようとしている /var/run/postgresql/.s.PGSQL.5432
ではなく、実際には /tmp/.s.PGSQL.5432
というソケットでリスニングしていると推測されます。 これは、DebianやUbuntuでハンドコンパイルやサードパーティ製のPostgreSQLパッケージを使用している場合によくある問題です。なぜなら、Unixドメインのソケットディレクトリのソースデフォルトは /tmp
ですが、Debianパッケージはそれを /var/run/postgresql
に変更するからです。
可能な回避策
/opt/djangostack-1.3-0/postgresql/bin/psql
を呼び出してください)。 Ubuntuが提供するパッケージを完全にアンインストールする(他の逆依存関係があるため、難しいかもしれません)。-H localhost
を使ってください。または同等の
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
netstat`の出力は、PostgreSQLサーバーがlocalhost'のポート5432でリッスンしていることを示しています。
PostgrSQL サーバがどのローカルの UNIX ソケットを使用しているかは、netstat を別の方法で実行することで確認できます。
netstat -lp --protocol=unix | grep postgres
いずれにせよ、PostgreSQLサーバがリッスンするインタフェースは postgresql.conf
で設定される。
OpenACSに基づいており、より最近のバージョンのPostgreSQLでは実行されないProject Openを使用しているため、Debian SqueezeでPostgreSQL 8.1をコンパイルする必要がありました。
デフォルトのコンパイル構成では、「unix_socket」が「/ tmp」に配置されますが、PostgreSQLに依存するProject Openは、「/ var / run / postgresql」で「unix_socket」を探すため機能しません。
postgresql.conf
には、ソケットの場所を設定する設定があります。 私の問題は、「/ tmp」と「psql」に設定することはできてもプロジェクトを開くことができないか、「/ var / run / postgresql」に設定して「psql」が機能せず、プロジェクトを開くことでした。
この問題の1つの解決策は、ピーターの提案に基づいて、次のように「/ var / run / postgresql」のソケットを設定し、「psql」を実行することです。
psql -h /var/run/postgresql
これは、ローカルの権限を使用してローカルに実行されます。 唯一の欠点は、単に「psql」よりもタイピングが多いことです。
誰かが行ったもう1つの提案は、2つの場所の間にシンボリックリンクを作成することでした。 これも機能しましたが、再起動時にリンクが消えました。 -h引数を使用する方が簡単かもしれませんが、 /etc/init.d
のPostgreSQLスクリプト内からシンボリックリンクを作成しました。 シンボリックリンクcreateコマンドを[スタート]セクションに配置しました。 もちろん、stop and start or retartコマンドを発行すると、既存のシンボリックリンクを再現しようとしますが、警告メッセージ以外は害はありません。
私の場合、代わりに:
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
私が持っています。
ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432
postgresql.conf
でunix_socketを /var/run/postgresql/.s.PGSQL.5432
に明示的に設定しました。
Postgresサービスがエラーなしで稼働しているか、Postgresサービスの開始にエラーがなく、それでも前述のエラーが発生している場合は、次の手順に従ってください。
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
ほとんどの場合、ステータスはケースとポストグレサービスでダウンします。
#format is pg_ctlcluster <version> <cluster> <action>
sudo pg_ctlcluster 9.6 main start
#restart postgres
sudo service postgres restart
このプロセスが成功しない場合、エラーが発生します。 /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`
postgres
が / var / lib / postgresql / version_no / main
の所有者であることを確認してください。
そうでない場合は、実行します。
sudo chown postgres -R /var/lib/postgresql/9.6/main/
誤ってPostgresユーザーを「ssl-cert」グループから削除したことがわかりました。 以下のコードを実行して、ユーザーグループの問題を修正し、権限を修正します。
#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
私の場合、それは /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
postgres-9.5サーバーでこの問題を解決できませんでした。 このサイトや他のサイトでの修正のすべての順列を試みて3日間の進行がゼロになった後、サーバーを再インストールして5日間分の作業を失うことにしました。 しかし、私は新しいインスタンスで問題を複製しました。 これは、私が行った壊滅的なアプローチをとる前に、それを修正する方法についていくつかの視点を提供するかもしれません。
まず、postgresql.confのすべてのロギング設定を無効にします。 これはセクションです。
# ERROR REPORTING AND LOGGING
そのセクションのすべてをコメントしてください。 次に、サービスを再開します。
再起動するときは、 /etc/init.d/postgresql start
または restart
を使用します。
再起動中にスーパーユーザーモードになっていると助かりました。 その操作のためだけにXウィンドウを開けました。 sudo -i
でそのスーパーユーザーモードを確立できます。
この単純なコマンド「psql -l -U postgres」でサーバーに到達できることを確認します。
それでも問題が解決しない場合は、次のことを考慮してください。
解決策を見つけようとしながら、多くのフォルダの所有権を変更していました。 私はおそらくそれらのフォルダの所有権と chmod
sをさらに2日間元に戻そうとしていることを知っていました。 これらのフォルダの所有権をすでに台無しにして、サーバーを完全にパージしたくない場合は、影響を受けるすべてのフォルダの設定を追跡して、元の状態に戻します。 別のシステムで並列インストールを実行し、すべてのフォルダの所有権と設定を体系的に確認することをお勧めします。 退屈ですが、データにアクセスできる場合があります。
アクセス権を取得したら、「postgresql.conf」ファイルの「#ERROR REPORTING AND LOGGING」セクションの関連する各行を体系的に変更します。 再起動してテストします。 ログのデフォルトのフォルダーが失敗の原因であることがわかりました。 特に「log_directory」についてコメントしました。 システムがログをドロップするデフォルトのフォルダは、 / var / log / postgresql
です。
Postgresのアンインストールは説得力がないことがわかりました。 これは私の問題を解決するのに役立ちます:
1。 postgresサーバーを起動します。
sudo systemctl start postgresql。
2。 サーバーが起動時に起動することを確認します。
sudo systemctlはpostgresqlを有効にします。
詳細情報はDigitalOceanサイト[こちらをご覧ください。][1]。
[1]:https://www.digitalocean.com/community/questions/is-the-server-running-locally-and-accepting-connections-on-unix-domain-socket-var-run-postgresql-s -pgsql-5432。
Flaskを使用しているので、これは質問とは正確には関係ありませんが、これは私が取得していた正確なエラーであり、これはアイデアを取得するための最も関連性の高いスレッドでした。
私のセットアップ:Linux用のWindowsサブシステム、ドッカーファイル付き/ makefile付きドッカーコンポーズ、Flask、Postgresql(テーブルで構成されるスキーマを使用)。
postgresに接続するには、次のように接続文字列をセットアップします。
。 フラスコからフラスコをインポートします。 app = Flask(__name__)。 app.config ['SQLALCHEMY_DATABASE_URI'] = "postgresql + pycopg2://< 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から来ました。
スキーマを設定します。
。 sqlalchemy import MetaDataから。 db = SQLAlchemy(app、metadata = MetaData(schema = "< schema_name>"))。
。
セッションを設定するときに、関数の検索パスを設定します。
。 db.session.execute( "SET search_path TO< schema_name>")。
。
Peter Eisentrautが説明したのとまったく同じ問題がありました。 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
も正しく構成されていることを確認することを忘れないでください。
私も同じ問題を抱えていました(Ubuntu 15.10(wily))。 sudo find / -name 'pg_hba.conf' -print
またはsudo find / -name 'postgresql.conf' -print
が空になりました。 それ以前は、postgresqlの複数のインスタンスがインストールされているようでした。
インストールされている、または依存関係の問題のリストが表示されている場合は、同様のものになる可能性があります。
.../postgresql
.../postgresql-9.x
等々。
その場合は、各パッケージを1 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
多くの疲れ果てた試みの後、私は他の投稿に基づいて解決策を見つけました。!
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