FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.1111.lock": Permission denied
psql: could not connect to server: Connection refused
Is the server running on host "S01B01" (10.10.222.193) and accepting
TCP/IP connections on port 1111?
Could you please help me in getting a permanent fix for this.
postgresql.conf:
data_directory = '/apps/ins/router/pgdata'
hba_file = '/apps/ins/router/pgdata/pg_hba.conf'
pg_hba.conf:
host all ins 10.10.10.10 255.255.255.255 trust
host all ins 127.0.0.1 255.255.255.255 trust
Both socket directories for PostgreSQL (/run/postgresql and /var/run/postgresql) are temporary directories created at boot time. (The /var/run/postgresql is in fact usually a symbolic link to /run/postgresql).
With the advent of systemd, a new mechanism called systemd-tmpfiles has been introduced to manage temporary files and directories.
Systemd-tmpfiles creates temporary directories during boot and sets their owner, group and permissions. It may read configuration files in three different locations. Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d.
Check those configuration directories for PostgreSQL configuration, usually postgresql.conf. (You will most likely find it at /usr/lib/tmpfiles.d/postgresql.conf.) The file will contain something like the following line:
d /run/postgresql 0755 postgres postgres -
You can change permissions, owner and group by editing that line. The recommended way to make such changes, however, is not to directly edit files under /usr/lib/tmpfiles.d/, but to copy configuration files over to /etc/tmpfiles.d/, and make the necessary changes in that copy instead.
Another way to fix the issue is to relocate the PostgreSQL lock file location. We can do so by using below query
ALTER SYSTEM SET unix_socket_directories='<any-existing-path-with-valid-permissions>, /tmp';
Related
I am trying to log in my postgresql.After researching I have solved a slew of many issues from a weird python dependency issue to creating sudoers with names and passwords as db to removing and reinstalling postgresql, still i cannot log in as the default user "postgres".
A simple error but i cannot find a straight forward answer.
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
NOTE:
My first installation,postgresql 11, I changed pg_hba.conf from peer to md5 but refused to login.
I removed postgresql 11 using many commands to purge it out of my system but am shocked anytime i do a locate postgress or locate psql i find a list of postgresql files. The most weird is running *apt-get remove --auto-remove postgresql* and sudo apt --purge remove postgresql -y then running service postgresql start only for it to start!Cannot wrap my head around this after trying several times, i thought it would be removed completely?!.
Though I can locate pg_hba.conf, the actual file is totally nonexitent when I ls the containing directory!!! Are there many /etc/ folders, seems am looking at the wrong /etc/ ?
I also faced this problem - You try this method, it's work for me.
If You using Linux then do according your server path .
Window Path ->
Go To -> C:\Program Files\PostgreSQL\11\data then Open pg_hba.conf
Find and replace md5 or sha256 to trust
local replication all trust (Change md5 or sha256 to trust)
host replication all trust (Change md5 or sha256 to trust)
Maybe this method helpful for you.
After login i got following message.
create -> /var/www/.pcppass
#insert:hostname:port:username:password
*:*:admin:postgres
*:*:postgres:postgres
*:*:administrator:postges
host$ sudo chown www-data .pcppass
... and it don't works :-/
After long time searching it seems the issue is related to pg_hba.conf and pool_hba.conf incompatibility when using wrong combinations of trusted and md5 host entries. See here and the FAQ. Those links shows how to correctly pair both conf files with this matrix :
You have to set default entries according to this matrix in order to get the so called "superuser" in pgpoolAdmin to be enabled and also to be able to allow connection throught pgpool.
I also found this answer here that helped me finally achieving to enable correct connection to backend servers: I had to mark the pgpool server as a trusted server on local network on pg_hba.conf on my postgresql servers.
I am bashing my head against the wall. its been 4 days.but psql is not connecting.
We have a small array of Greenplum database.In that, We have the master node. when i am trying to use psql utility
Getting this error :
[gpadmin#master gpseg-1]$ psql
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
We tried
on searching for postmaster.pid files.
We have removed it.But still, error remains.
Use a command like ( netstat -ln; ps -ef ) | egrep '(postgres)|(postmaster)|(5432)' to try to determine whether or not an instance of the postgres server is running.
If the postmaster is not running, remove the postmaster.pid file and restart the database. While I don't use the Greenplum database, I see that instructions are here: Starting and Stopping the Greenplum Database. Do not remove the postmaster.pid file without making sure the database is not running, and note that removing the postmaster.pid file without starting the database is pointless.
It may be wise to open your postgresql.conf file and see if the listen_addresses, port, unix_socket_directory, unix_socket_group, and unix_socket_permissions settings might be a source of issues.
Since the error message referenced specifically mentions the socket file, look most closely at unix_socket_directory, unix_socket_group, and unix_socket_permissions.
If unix_socket_directory is pointing somewhere other than /tmp, then various workarounds exist.
Alternatively, and presuming that the server is running, one might try to locate the socket file without looking in the postgresql.conf file, though this might make it a bit harder to address permissions, port, etc. issues. A tool like locate, find, etc., may be used in conjunction with sudo or by the root user.
$ sudo find /tmp /var -name .s.PGSQL.5432
Presuming that the location of the .s.PGSQL.5432 file issue is the root cause of your problem, specifying the socket file location on the psql command-line is probably the most straightforward workaround. In example, if the *.s.PGSQL.5432 file is in /var/pgsql_socket directory as it is on some systems, try this, but, of course, use the actual directory where .s.PGSQL.5432 is located:
$ pgsql -h /var/pgsql_socket
If the .s.PGSQL.5432 file IS in /tmp, then the problem is more likely one of permissions, and consulting the postgresql.conf file is advised, and probably the user attempting the psql command will have to be added to a group that has access to the socket file. (Remember, log out and back in after changing group membership.)
Though the page does not necessarily seem to directly relate to this issue, do consider the Accessing the Database help as needed.
What does gpstate show? If it cannot connect, make sure the GPDB master is running:
ps ax | grep 'M master'
If the master is running, it will also show the port the master is listening on.
For the gpadmin Linux account, look in the ~/gpAdminLogs directory. There should be one or more startup logs that you can check.
That error normally means that the database is stopped. You should never remove this file unless it was left behind after a bad crash, where the file was never cleaned out. You would normally detect that situation when you start the db again - it would complain the file already existed.
I tend to look for
ps -eaf|grep -i silent
to see the postmaster processes.
If the master is down, but the segments are up, you will need to start the master only
gpstart -m
then stop everything with
gpstop -M fast
Causes for failures should be in $MASTER_DATA_DIRECTORY/pg_log and possibly in the corresponding segment pg_log directories. There may also be core files if the master or segments had a panic.
I just installed Postgres.app on my Mac, and I need to make some specific configuration to server. For example I want to use different port, not 5432.
I found that it have postgresql.conf at ~/Library/Application\ Support/Postgres/var/postgresql.conf, but even if I change value of port = to something other, it listen on 5432 after server restart.
Seems that this postgresql.conf isn't used by Postgress.app. Where it stores server configuration files?
The postgresql.conf-file at ~/Library/Application\ Support/Postgres/var/ is used by Postgres.app. The only problem: if you change the port in that file, that change will not be reflected in the menu-bar. So the elephant over there will still say "Running on Port 5432", although postgres might be running on, for example, port 5433. (Mac OS X 10.8.2, Server.app 2.2, Postgres.app 9.2.2.0)
I can see the output from ps aux |grep post
/Applications/Postgres.app/Contents/MacOS/bin/postgres -D /Users/chenc26/Library/Application Support/Postgres/var -p5432
So I think there must be some config in this app to specify the CLI parameter which ignore the value from config file.
I'm running a Mavericks 10.9.3 and opening Postgres app v9.3 config via nano ~/Library/Application\ Support/Postgres/var-9.3/postgresql.conf and uncommenting the port = 5432 line, then changing it to, say, 5433 did the trick for me. (Restarting the app was required, as the config file mentions). Afterwards the app correctly displays that it is running on port 5433.
If correctly changing the content of postgresql.conf, then restarting the PostgreSQL server doesn't change the port it's listening on, you're almost certainly editing the wrong postgresql.conf.
On other platforms, PostgreSQL puts a copy of its default version of postgresql.conf in the data directory. So you're liable to find at least two copies of all the configuration files somewhere on your computer--usually one in the directory where the distribution or source was downloaded or uncompressed, and one in the data directory. On your Mac, if you're using version 9.1, the data directory might be
/Library/PostgreSQL/9.1/data/
Check for a postgresql.conf there. If you find one, consider making a copy of it to replace the one you edited. (So the one you edited will again be an unedited version.)
In 2022, I can't just edit the server.conf file. It looks like instead, I've had to do this from the GUI to change the port which the command line parameters refer to:
... bin/postgres -D /Users/MyUser/Library/Application Support/Postgres/var-11 -p 6543
The way I was able to make the change was to:
Open the Postgres elephant icon in the top bar.
Select "Open Postgres"
Stop the server.
Click on server settings.
Then, change the port in the simple input.
After this, start the server and find that the port has changed.
This works for the Postgres.app (version 11 on my desktop).
I am trying to COPY a file into a table in PostgreSQL. The table owner is postgres and the file owner is postgres.
The file is in /tmp.
Still I am getting the error message:
could not open file "/tmp/file" for reading: Permission denied
I don't understand what I am doing wrong as all the posts I've found say that if I have the file in /tmp and owner is postgres then the COPY command should work.
A guess: You are using Fedora, Red Hat Enterprise Linux, CentOS, Scientific Linux, or one of the other distros that enable SELinux by default.
Either and on your particular OS/version the SELinux policies for PostgreSQL do not permit the server to read files outside the PostgreSQL data directory, or the file was created by a service covered by a targeted policy so it has a label that PostgreSQL isn't allowed to read from.
You can confirm whether or not this is the problem by running, as root:
setenforce 0
then re-testing. Run:
setenforce 1
to re-enable SELinux after testing. setenforce isn't permanent; SELinux will be automatically re-enabled on reboot anyway. Disabling SELinux permanently is not usually a good solution for issues like this; if you confirm the issue is SELinux it can be explored further.
Since you have not specified the OS or version you are using, the PostgreSQL version, the exact command you're running, ls -al on the file, \d+ on the table, etc, it's hard to give any more detail, or to know if this is more than a guess. Try updating your answer to include all that and an ls --lcontext of the file too.
COPY with a file name instructs the PostgreSQL server to directly read from or write to a file. The file must be accessible by the PostgreSQL user (the user ID the server runs as) and the name must be specified from the viewpoint of the server. (source: postgresql documentation)
So the file should be readable (or writable) by the unix user under which postgresql server is running (i.e not your user!). To be absolutly sure, you can try to run sudo -u postgres head /tmp/test.csv (assuming you are allowed to used sudo and assuming the database user is postgres).
If that fails, it might be an issue related to SELinux (as mentioned by Craig Ringer). Under the most common SELinux policy (the "targeted" reference policy), used by Red Hat/Fedora/CentOS, Scientific Linux, Debian and others... the postgresql server process is confined : it can only read/write a few file types.
The denial might not be logged in auditd's log file (/var/log/audit/audit.log) due to a donaudit rule. So the usual SELinux quick test apply e.g: stop SELinux from confining any process by running getenforce;setengorce 0;getenforce, then test postgresql's COPY. Then re-activate SELinux by running setenforce 1 (this command modify the running state, not the configuration file, so SELinux will be active (Enforcing) after reboot.
The proper way to fix that is to change the SELinux context of the file to load. A quick hack is to run:
chcon -t postgresql_tmp_t /tmp/a.csv
But this file labelling will not survive if hte filesystem is relabel or if you create a new file. You will need to create a directory with an SELinux file context mapping :
which semanage || yum install policycoreutils-python
semanage fcontext -a -t postgresql_tmp_t '/srv/psql_copydir(/.*)?'
mkdir /srv/psql_copydir
chmod 750 /srv/psql_copydir
chgrp postgres /srv/psql_copydir
restorecon -Rv /srv/psql_copydir
ls -Zd /srv/psql_copydir
Any file created in that directory should have the proper file context automatically so postgresql server can read/write it.
(to check the SELinux context under which postgres is running, runps xaZ | grep "postmaste[r]" | grep -o "[a-z_]*_t", which should print postgresql_t. To list the context types to which postgresql_t can write, use sesearch -s postgresql_t -A | grep ': file.*write'. the command sesearch belong to the setools-console RPM package).