How to fix this error?
psql: error: 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"?
We use Docker, Postgres12, Wercker.
When we run this command in Wercker, we can't create a database.
But we can create it in my local Ubuntu environment.
sudo docker exec docker_postgres_1 psql -U postgres -c 'create database postgres_dev'
First, you need to make sure the socket file is located in /var/run/postgresql/.s.PGSQL.5432. To check that
$ cat /var/run/postgresql/.s.PGSQL.5432
if result shows something, then the problem is anything else. But, if file is not there you need to check /tmp dir (specially for OSX Homebrew users)
$ cd /tmp
$ l
total 16
drwxrwxrwt 7 root wheel 224B Mar 11 08:03 .
drwxr-xr-x 6 root wheel 192B Jan 23 18:35 ..
-rw-r--r-- 1 root wheel 65B Nov 7 22:59 .BBE72B41371180178E084EEAF106AED4F350939DB95D3516864A1CC62E7AE82F
srwxrwxrwx 1 shiva wheel 0B Mar 11 08:03 .s.PGSQL.5432
-rw------- 1 shiva wheel 57B Mar 11 08:03 .s.PGSQL.5432.lock
drwx------ 3 shiva wheel 96B Mar 10 17:11 com.apple.launchd.C1tUB2MvF8
drwxr-xr-x 2 root wheel 64B Mar 10 17:10 powerlog
Now, there are two ways you can solve the error
Solution One
You can change the application configuration to see for sockets at /tmp/.s.PGSQL.5432
For Rails Users
# config/database.yml
default: &default
adapter: postgresql
pool: 5
# port:
timeout: 5000
encoding: utf8
# min_messages: warning
socket: /tmp/.s.PGSQL.5432
Solution Two
You can create symlinks to the expected location
$ sudo mkdir /var/pgsql_socket
$ sudo ln /tmp/.s.PGSQL.5432 /var/pgsql_socket/
```
Then the error should go.
Hope this helps.
Related
We have installed postgres v12 on ubuntu 20.04 (with apt install -y postgresql postgresql-contrib) and wish to enable archiving to /data/db/postgres/archive by setting the following in postgresql.conf:
max_wal_senders=2
wal_keep_segments=256
wal_sender_timeout=60s
archive_mode=on
archive_command=cp %p /data/db/postgres/archive/%f
However the postgres service fails to write there:
2022-11-15 15:02:26.212 CET [392860] FATAL: archive command failed with exit code 126
2022-11-15 15:02:26.212 CET [392860] DETAIL: The failed archive command was: archive_command=cp pg_wal/000000010000000000000002 /data/db/postgres/archive/000000010000000000000002
2022-11-15 15:02:26.213 CET [392605] LOG: archiver process (PID 392860) exited with exit code 1
sh: 1: pg_wal/000000010000000000000002: Permission denied
This directory /data/db/postgres/archive/ is owned by the postgres user and when we su postgres we are able to create and delete files without a problem.
Why can the postgresql service (running as postgres) not write to a directory it owns?
Here are the permissions on all the parents of the archive directory:
drwxr-xr-x 2 postgres root 6 Nov 15 14:59 /data/db/postgres/archive
drwxr-xr-x 3 root root 21 Nov 15 14:29 /data/db/postgres
drwxr-xr-x 3 root root 22 Nov 15 14:29 /data/db
drwxr-xr-x 5 root root 44 Nov 15 14:29 /data
2022-11-15 15:02:26.212 CET [392860] DETAIL: The failed archive command was: archive_command=cp pg_wal/000000010000000000000002 /data/db/postgres/archive/000000010000000000000002
So, your archive_command is apparently set to the peculiar string archive_command=cp %p /data/db/postgres/archive/%f.
After the %variables are substituted, the result is passed to the shell. The shell does what it was told, which is to set the (unused) environment variable 'archive_command' to be 'cp', and then tries to execute the file pg_wal/000000010000000000000002, which is not allowed to because it doesn't have the execute bit set.
I don't know how you managed to get such a deformed archive_command, but it didn't come from anything you showed us.
In uWSGI, if I change my socket location to /tmp/api, the website renders. However, if I change the socket address to /srv/www/api/, I get a 502 gateway error.
I believe this is due to a permissions issue regarding the /srv folder and the Nginx/uWSGI users.
In /var/log/nginx/error.log:
*1 connect() to unix:///srv/www/api/app.sock failed (2: No such file or directory) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: api.example.com, request: "GET / HTTP/2.0", upstream: "uwsgi://unix:///srv/www/api/app.sock:", host: "api.example.com"
The Flask project code is located in /srv/www/api. I am logged in as username user.
Permissions:
$ ll -ld /srv/www/api/
drwxrwxr-x 4 www-data www-data 4096 Jun 28 20:52 /srv/www/api/
$ ll -ld /srv/www
drwxrwxr-x 4 username www-data 4096 Jun 27 21:41 /srv/www
$ ll -ld /srv
drwxrwxr-x 4 username username 4096 Jun 27 21:37 /srv
$ ll -ld /tmp
drwxrwxrwt 9 root root 4096 Jun 28 23:05 /tmp
User groups:
$ groups username
username : username sudo dev
$ groups www-data
www-data : www-data dev
$ grep 'dev' /etc/group
dev:x:1001:username,www-data
I have several users setup to be in the dev group. The goal is so that users in the group would be able to read and write to /srv without also being in the root group (is this a bad practice?).
/srv/www/api/app.ini:
[uwsgi]
module = wsgi:app
master = true
processes = 5
socket = /tmp/app.sock
chmod-socket = 660
vacuum = true
die-on-term = true
/etc/nginx/sites/sites-available/api.example.com (location section):
location / {
include uwsgi_params;
uwsgi_pass unix:/tmp/app.sock;
}
Is there a way to fix my permissions setup so that:
The socket would be able to be created in that folder
Users in the dev group without sudo would also be able to read and write the /srv folder and subdirectories
I figured this out. I ended up setting the owners for my folder to:
chown -R username:www-data /srv/www/api
I also made sure to restart the systemctl service after each change. I don't remember doing that earlier so that was very likely the reason why nothing was working even after all the changes made. I only restarted Nginx and not the service itself -- the one responsible for creating the sockets.
To restart the systemctl service:
sudo systemctl restart <service_name>
I am using PostgreSQL 9.5 on Ubuntu 16.04 LTS.
I receive the below error when I type 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"?
On checking the logs in /var/log/postgresql/postgresql-9.5-main.log, I see the error as:
2018-11-26 13:17:41 IST [3508-1] FATAL: could not access private key file "/etc/ssl/private/ssl-cert-snakeoil.key": Permission denied
Below are the permissions of the /etc/ssl/private and ssl-cert-snakeoil.key files:
vivek#vivek-ThinkPad-E480:~$ ls -l /etc/ssl
total 36
drwxr-xr-x 2 root root 20480 Nov 22 13:06 certs
-rwxr-xr-x 1 root root 10835 Dec 8 2017 openssl.cnf
drwxr--r-- 2 root ssl-cert 4096 Nov 22 13:06 private
vivek#vivek-ThinkPad-E480:~$ sudo ls -l /etc/ssl/private
total 4
-rw-r----- 1 root ssl-cert 1704 Nov 22 13:06 ssl-cert-snakeoil.key
The postgres user is also added to the group ssl-cert.
vivek#vivek-ThinkPad-E480:~$ getent group ssl-cert
ssl-cert:x:112:postgres
NOTE: I found that there is no server.key present in /var/lib/postgresql/9.5/main.
I also posted this on DBA Stackexchange, but no response as yet.
Can anyone guide me in the right direction in setting permissions?
That can never work, and your server will not be able to start, because the OS user postgres has no permissions to access files in etc/ssl/private.
To allow users in the group ssl-cert to access files in the directory, run
chmod g+x /etc/ssl/private
While you're at it, make sure that /etc/ssl has the required permissions.
To test if everything works, become user postgres and try to read the file.
After some time the Postgres database stopped working of my live server. I'm working on this server from last 8 months. Now suddenly it's stopped working.
when I try to enter the command, psql produces an error
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"?
enter image description here
I'm using odoo8.
First, you need to make sure the socket file is located in /var/run/postgresql/.s.PGSQL.5432. To check that
$ cat /var/run/postgresql/.s.PGSQL.5432
if result shows something, then the problem is anything else. But, if file is not there you need to check /tmp dir (specially for OSX Homebrew users)
$ cd /tmp
$ l
total 16
drwxrwxrwt 7 root wheel 224B Mar 11 08:03 .
drwxr-xr-x 6 root wheel 192B Jan 23 18:35 ..
-rw-r--r-- 1 root wheel 65B Nov 7 22:59 .BBE72B41371180178E084EEAF106AED4F350939DB95D3516864A1CC62E7AE82F
srwxrwxrwx 1 shiva wheel 0B Mar 11 08:03 .s.PGSQL.5432
-rw------- 1 shiva wheel 57B Mar 11 08:03 .s.PGSQL.5432.lock
drwx------ 3 shiva wheel 96B Mar 10 17:11 com.apple.launchd.C1tUB2MvF8
drwxr-xr-x 2 root wheel 64B Mar 10 17:10 powerlog
Now, there are two ways you can solve the error
Solution One
You can change the application configuration to see for sockets at /tmp/.s.PGSQL.5432
For Rails Users
# config/database.yml
default: &default
adapter: postgresql
pool: 5
# port:
timeout: 5000
encoding: utf8
# min_messages: warning
socket: /tmp/.s.PGSQL.5432
Solution Two
You can create symlinks to the expected location
$ sudo mkdir /var/pgsql_socket
$ sudo ln /tmp/.s.PGSQL.5432 /var/pgsql_socket/
Then the error should go.
Hope this helps.
Note: Your default socket directory may not be /tmp
Did you update/upgrade your database?
Did you start a docker container that interfered with any of your data-store/socket file locations?
This probably doesn't fit your situation exactly, but maybe it will provide some insight:
Sometimes when you try
sudo systemctl start postgresql.service
and the systemd status says it is started but you still get that error message when trying to connect, try this instead:
sudo pg_ctlcluster <version> <cluster> <action>
which in my case had been
sudo pg_ctlcluster 13 main start
I have a docker image that runs fine on Debian jessie (with kernel 3.16), and when I moved that image to an Ubuntu host (kernel 3.13), postgresql failed to come up. I've narrowed it down to a difference in behaviour when accessing a certain file, and my only explication for it is the difference in host kernel. I'd like to know if anyone has confirm this to be the problem, or has ideas on a possible different root cause for it.
The following sequence of commands shows the problem. First on the 'good' host:
root#lava-docker:/etc# ls -l /etc/ssl/private/ssl-cert-snakeoil.key
-rw-r----- 1 root ssl-cert 1708 Oct 20 19:31 /etc/ssl/private/ssl-cert-snakeoil.key
root#lava-docker:/etc# su - postgres
postgres#lava-docker:~$ ls -l /etc/ssl/private/ssl-cert-snakeoil.key
-rw-r----- 1 root ssl-cert 1708 Oct 20 19:31 /etc/ssl/private/ssl-cert-snakeoil.key
postgres#lava-docker:~$ ls -ld /etc/ssl/private
drwx--x--- 2 root ssl-cert 4096 Oct 20 19:31 /etc/ssl/private
postgres#lava-docker:~$ id
uid=110(postgres) gid=115(postgres) groups=115(postgres),114(ssl-cert)
now the same sequence on the 'bad' host:
root#lava-docker:/# ls -l /etc/ssl/private/ssl-cert-snakeoil.key
-rw-r----- 1 root ssl-cert 1708 Oct 20 19:31 /etc/ssl/private/ssl-cert-snakeoil.key
root#lava-docker:/# su - postgres
postgres#lava-docker:~$ ls -l /etc/ssl/private/ssl-cert-snakeoil.key
ls: cannot access /etc/ssl/private/ssl-cert-snakeoil.key: Permission denied
postgres#lava-docker:~$ ls -ld /etc/ssl/private
drwx--x--- 2 root ssl-cert 4096 Oct 20 19:31 /etc/ssl/private
postgres#lava-docker:~$ id
uid=110(postgres) gid=115(postgres) groups=115(postgres),114(ssl-cert)
as can be seen, even though the file and directory permissions are identical, as is the user configuration (same docker image after all), on one postgres user can see it, but not on the other.
This directory is not mounted with volume option, it is under aufs control
This might be the aufs issue where the permissions in one Docker layer can't be made less restrictive than those in a lower layer.
https://github.com/moby/moby/issues/1295#issuecomment-269058662
The solution seems to be to not use aufs. Use overlay2 instead.
Alternatively it seems if you have Docker 17.09 or later you can use the --chown flag on ADD/COPY. https://stackoverflow.com/a/44766666/127670