I receive error
FATAL: could not create lock file "postmaster.pid": Permission denied
when trying to execute command
pg_ctl restart --pgdata "D:\Program Files\PostgreSQL\8.3\data"
Full rights for postgres user to D:\, D:\Program Files\, D:\Program Files\PostgreSQL\ and D:\Program Files\PostgreSQL\8.3\data are set. What else I need to do?
I set full access to D:\Program Files\PostgreSQL\8.3\data to Users group and now it works. Detail are at
http://forumserver.twoplustwo.com/114/pokertracker/cant-connect-db-422617/
(last post).
You need to ensure that the user postgres has write permission to the postgres data_directory configured in postgresql.conf file. In my case /var/lib/postgresql/9.5/main/ if not add permission with:
chmod u+w /var/lib/postgresql/9.5/main/
You have to make ensure that the user postgres has right to write & execute /var/run/postgresql
sudo chmod 765 /var/run/postgresql
sudo chown postgres /var/run/postgresql
I had this issue due to installing postgres-xc and the solution was to remove it.
pg_ctl is the most common (and recommended) way used to start/stop/etc postgres.
For some reason it was not part of my postgres install.
After duckduckgo'ing a little, I installed postgre-xc which includes pg_ctl.
postgres-xc changed the owner of /var/run/postgresql from postgres to postgres-xc.
This caused lots of headaches and warnings about being unable to lock the pid file.
So, I removed postgres-xc (and reverted the owner of /var/run/postgresql to postgres).
Instead of using pg_ctl, I control postgres using
service postgresql status
or
/etc/init.d/postgresql status.
Hopefully this will help someone.
postgresql serviceis logined in NETWORK SERVICE, so you must needed make data dir(ie: "D:\Program Files\PostgreSQL\8.3\data") is full control over to NETWORK SERVICE group.
I just added my username to group "postgres"; all went fine
sudo adduser your-user-name postgres
Ciao
Related
I try to start postgresql : /usr/pgsql-11/bin/pg_ctl -D appli/postgres/data/ -l logfile start
but I don't understand why I have always this error in my logfile :
FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied
I tried to change permission but I get always Permission denied :
chown -R postgres:postgres /var/run/postgresql
chmod 755 /var/run/postgresql
Edit postgresql.conf and change unix_socket_directoriesback to the factory default value /tmp.
Alternatively, start PostgreSQL as operating system user postgres.
If you installed from source, the directory should probably be '/tmp'. If you installed from a repository, the shipped start-up script should handle the permissions for you. Why not use that rather than running pg_ctl yourself?
I had the same problem and what did it for me was creating the directory "postgresql" which didn't exist previously for some bizarre reason and running
sudo chown postgres /var/run/postgresql
after that pg_ctl was able to create the lock file without problems.
I ran into it with an alpine docker image. As it turned out they changed the default:
Using /tmp for sockets allows everyone to spoof a PostgreSQL server.
There are 2 options:
Create the /run/postgresql dir:
mkdir /run/postgresql && chown postgres: /run/postgresql
Change unix_socket_directories in postgresql.conf (unix_socket_directories = '/tmp').
Cannot find any tutorials that show what you do when you deleted default postgres user through root.
Created local postgres server through sudo apt-get install postgresql postgresql-contrib. Inside shell, typed psql and was able to initiate db.
Logged into root and deleted postgres account in linux while trying something out.
2a: sudo pkill -KILL -u postgres
2b: sudo userdel postgres
Deleted postgres server. Re-installed. Got user not found when trying to log into postgres user account through shell.
Tried running postgres server through root and got unable to connect to server through shell.
Re-created postgres user account through root: sudo adduser postgres --disabled-password.
Postgres user through root: sudo usermod -a -G sudo postgres
Still getting unable to connect to server: connection refused. Logged into postgres user. No change.
Re-installed postgres. Same error.
Suggestions?
Thanks a bunch.
You don't exactly need a user who is named postgres, you need a user who owns the data directory, the binaries and configuration files. You should check which uid and gid are now associated with your data directory, then create a user with that specific uid and gid. But check who those id's belong to first. If no user currently has those uid and gid then create a new user with those values:
useradd -u 123 -g 456 postgres
Alternatively, re-create user postgres and assign data directory and binaries to that new user (assuming group postgres still exists):
useradd -G postgres postgres
chown -r postgres:postgres $PGDATA
chown -r postgres:postgres /wherever/bin/is
chown -r postgres:postgres /wherever/conf/is
Found the answer, Read below.
Been on another rabbit hole hunt. Heard about the data file,
how someone deleted it and it has all kinds of info(config
stuff) in there. Also heard how some config files get left
around even after uninstalling the program. Not just config
files but a lot of other files get left around also with
other programs that I have installed and uninstalled.
So here I go to start just deleting a bunch of stuff and then
I go to this link to postgresql.org where it shows about
where the 'data file' is. Or I think maybe it is the 'data file'.
This page says the data file is usually in
'/var/lib/pgsql/data'. I uninstalled postgresql so I didn't
have a pgsql folder but I saw that there was a 'postgresql' folder
there. So I deleted it and now all is well. Now I am
able to reinstall postgresql with no problems, no cluster
problems or nothing. The 'posgresql' folder had 2 hidden files,
I've learned from the past to always check if there are
hidden files. These hidden files names were 'bash_history' and
'psql_history' & you know they were somehow
stopping a fresh complete installation. After deleting them I
was able to reinstall postgresql, with a newly created
'postgres' user waiting for me.
Its 3:43am in the morning & another rabbit hole in the books.
Happy hunting.
Here is the link that I mentioned:
[https://www.postgresql.org/docs/current/storage-file-layout.html][1]
I restarted my Postgres server but now.
I checked my "pgstartup.log" log file. This says:
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok
Success. You can now start the database server using:
/usr/bin/postgres -D /var/lib/pgsql/data
/usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start
FATAL: could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission denied
FATAL: could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission denied
Do you think deleting /tmp/.s.PGSQL.5432.lock would work ?
Postgres cannot write a file to /tmp because of permissions set on /tmp directory.
As root user execute in terminal:
chmod 1777 /tmp
PostgreSQL normally deletes the lock file when terminates correctly.
It is probably due to another PostgreSQL instance running with a different user that has been terminated abnormally (a kill -9 to postmaster).
So, if you are sure no Postgres processes are running, you can probably delete that file without any issue. You should also check with the ipcs command if there is any stale shared memory segment, and in that case delete it with ipcrm.
Probably the be best way to address all these things at once is rebooting the server.
P.S.: never kill -9 any PostgreSQL process.
It looks like you probably have another PostgreSQL instance running on the same port as a different user, or you previously started this PostgreSQL instance as a different user then stopped it uncleanly.
Check the ownership of /tmp/.s.PGSQL.5432.lock:
ls -l /tmp/.s.PGSQL.5432.lock
Does it match the user you're running PostgreSQL as?
It's relatively harmless to delete the lock files in /tmp/. (Never, ever delete the postmaster.pid lock file though). If the other PostgreSQL instance is still running you'll lose the ability to connect to it over a unix socket, or you might get an error about being unable to bind to port 5432 on tcp.
I agree with #mnencia that a server reboot is the best option if it's easy and practical.
If you know that no other Postgres processes are running, please delete these 2 files and try again:
$ sudo rm /tmp/.s.PGSQL.5432.lock
$ sudo rm /tmp/.s.PGSQL.5432
Then, you would be able to run the server as a background process with the command:
$ pg_ctl -D /usr/local/var/postgres start
If you are in OS X, put the alias in the.bash_profile as below:
alias pgb='pg_ctl -D /usr/local/var/postgres start'
Now, source it with the command:
$ source ~/.bash_profile
The Postgres server will run with the command:
$ pgb
To me it was permission problem for database file, It was group/world readable. And that was wrong! Database file should be 0700. Aft
Thanks for the suggestions.
First I tried changing the permission of the lock file but it didn't work
Later I deleted the lock file which resolved my issue.
Thanks
Thanks.
I was trying to install postgres on my mac.I was receiving
FATAL: could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission denied
After deleting the /tmp/.s.PGSQL.5432.lock file, the server started working.
Yes, I had the same issue, and I fixed it by running this command
$ sudo rm /tmp/.s.PGSQL.5432.lock
$ sudo rm /tmp/.s.PGSQL.5432
$ pg_ctl -D /usr/local/var/postgres start
I killed the Postgress service running on port 5432 which is something you should never do, this can be done unknowingly. So running the above commands would remove the lock file, and now when you start a new Postgres server, it would create a new process for you
Not sure, but I think it's the lock file that another Postgres instance is working on.
Restart the PC, and then that instance will leave access to that lock file. And the Postgres server will start. It works for me.
I find I have the wreckage of two old PostgreSQL installations on Ubuntu 10.04:
$ pg_lsclustersVersion Cluster Port Status Owner Data directory Log file
Use of uninitialized value in printf at /usr/bin/pg_lsclusters line 38.
8.4 main 5432 down /var/lib/postgresql/8.4/main /var/log/postgresql/postgresql-8.4-main.log
Use of uninitialized value in printf at /usr/bin/pg_lsclusters line 38.
9.1 main 5433 down /var/lib/postgresql/9.1/main /var/log/postgresql/postgresql-9.1-main.log
$
Attempts to perform basic functions return errors, for instance:
createuser: could not connect to database postgres: 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"?
More information comes when I try to start the database server:
$ sudo /etc/init.d/postgresql start
* Starting PostgreSQL 9.1 database server
* Error: The cluster is owned by user id 109 which does not exist any more
...fail!
$
My question: how do I completely remove both clusters and set up a new one? I've tried removing, purging, and reinstalling postgresql, following the advice here: https://stackoverflow.com/a/2748644/621762. Now pg_lsclusters shows no clusters in existence, but the No such file or directory error persists when I try to createuser, createdb or run psql. What have I failed to do?
First, that answer you linked to was pretty unsafe - hand-editing /etc/passwd ?!? dselect where an apt wildcard would do? Crazy stuff. I'm not surprised you're having issues.
As for the no such file or directory messages: You need to make sure you have a running PostgreSQL server ("cluster") before you can use admin commands like createdb, because they make a connection to the server. The No such file or directory message is telling you that the server doesn't exist or isn't running.
Here's what's happening:
Ubuntu uses pg_wrapper to manage multiple concurrent PostgreSQL instances. The issues you're having are really with pg_wrapper.
Ideally you would've just used pg_dropcluster to get rid of the unwanted clusters. Unfortunately, by following bad advice it sounds like you've got your system into a bit of a messed-up state where the PostgreSQL packages are half-installed and kind of mangled. You need to either repair the install, or totally clean it out.
I'd clean it out. I'd recommend:
Verify that pg_lsclusters lists no database clusters
apt-get --purge remove postgresql\* - this is important
Remove /etc/postgresql/
Remove /etc/postgresql-common
Remove /var/lib/postgresql
userdel -r postgres
groupdel postgres
apt-get install postgresql-common postgresql-9.1 postgresql-contrib-9.1 postgresql-doc-9.1
It's possible that the apt-get --purge step will fail because you've removed the user IDs, etc. Re-creating the postgres user ID with useradd -r -u 109 postgres should allow you to re-run the purge successfully then delete the user afterwards.
This answer is not directly about removing a postgres instance, rather, about resoliving the issue,
Error: The cluster is owned by user ...
I got this error while trying to spin up a docker container pointed to a postgres data directory that was produced via a different container (on a different host machine).
The error is directly related to directory ownership. In my case, the system was unable to find the user that certain postgres directories was owned by in the current environment. By re-owning those directories to the right user resolves the issue. Following is an example mapping (that worked for me):
chown -R postgres:postgres /var/lib/postgresql
chown -R postgres:postgres /etc/postgresql
chown -R postgres:postgres /var/log/postgresql
chown -R postgres:postgres /var/run/postgresql
I cannot "service postgresql start" by root:
Startup Log: /usr/bin/postmaster: error while loading shared
libraries: libz.so.1: failed to map segment from shared object:
Permission denied
I cannot "service postgresql start" by postgres:
Startup Log:runuser: cannot set groups: Operation not permitted
But I can start it by postgres user with command:
postmaster -D /usr/local/pgsql/data
Why?
When I installed, I used
initdb -D /usr/local/pgsql/data
not
service postgresql initdb
So I afterwards changed init.d/postgresql script with the new path. Is this causing problem?
Caused for me by creating the DB with
/etc/init.d/postgresql-9.3 initdb
Recreating with
service postgresql-9.3 initdb
solved the issue.
As Craig said this is either a file permission issue or a selinux issue. If it is a file permissions issu, that is easy enough to fix (give read/execute perms).
If it is an selinux issue your best option is to run audit2allow to identify the problem and ensure that selinux is configured to allow the correct access.