On my MacBook I have two user profiles. One for work and one for personal use. I develop on both and recently I've wanted to start a local Postgres server but I can't seem to do this. When I try to run pg_ctl -D /usr/local/var/postgres I get this error:
pg_ctl: could not open PID file "/usr/local/var/postgres/postmaster.pid": Permission denied
I also can't run it as a super user as it says pg_ctl: cannot be run as root
I think this might be because I installed Postgres on my work user profile and even though I can still access the CLI I can't run the Postgres server as I don't have the right permissions on my personal user profile.
Apologies in advance if this is a really obvious error, I am new to development 😅
If there is a PID file present, either the database is running, or you did not shut it down properly, and it crashed.
Anyway, your idea is doomed. Only the user who owns the database files can start the database server.
Perhaps you can use sudo:
sudo -u dbowner pg_ctl start -D /usr/local/var/postgres
But I guess that you misunderstand the principle of client-server software.
You should have the system start PostgreSQL as a service, running as the database owner. Then it is irrelevant as which operating system user you run the client software (unless you are using peer authentication in PostgreSQL).
Related
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.
Something weird is happening with my postgres installation after I upgraded to version 9.3.2 homebrew.
Sometimes and not every time, if I enter psql I get this error message:
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"?
It also appears that postgres is running because if I try and stop postgres with this command:
pg_ctl -D /usr/local/var/postgres stop -s -m fast
I get this response:
pg_ctl: server does not shut down
If I look in the server.log I can see the following entries:
FATAL: lock file "postmaster.pid" already exists HINT: Is another
postmaster (PID 208) running in data directory
"/usr/local/var/postgres"?
After some frantic googling, I am able to cure this by entering these commands:
launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
rm ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
I would like to first of all understand what is happening and second of all I would like to fix it once and for all.
Can anyone explain what might be happening and a cure?
First, try to pull up a log on PostgreSQL, on OSX (and with PG 9.3) this will most likely be here:
/Library/PostgreSQL/9.3/data/pg_log
Check this log and see if there are any entires in it that may explain more of what is happening. Post it here or in a past bin somewhere. This can help the community to debug the issue.
Next, the reason why 'pg_ctl' says the server is not shutdown is because you have a stale socket file and/or a stale .plist file that did not get removed on last shutdown. This may indicate that the PostgreSQl daemon was "crashed" or was shutdown by force and did not have a clean finish.
The commands you used removed the stale files and thus made way for a new socket file to be created.
Also it is important to know if this was a minor or a major upgrade of PostgreSQL. Major upgrades always require a migration of the data directory. Running an old PostgreSQL data directory with a new engine might have unexpected results.
I'm new to psql, and am having some issues that I think are being caused by a misplaced .conf file. When I tried to log into a database I created earlier I get an error
$ psql corporation
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
Based on the psql docs it looks like the server isn't running and ps confirms this. Since I don't remember having to start it last time I used psql I was a little confused, but it seemed easy to fix. Unfortunately, my attempts to start the sever have not worked. Using the first method suggested by the docs gets me
$ postgres -D /usr/local/pgsql/data
postgres cannot access the server configuration file "/usr/local/pgsql/data/postgresql.conf": No such file or directory
While the second method results in
$postgres -D /usr/local/pgsql/data >logfile 2>&1 &
[1] 3165
Ps confirms that neither of these methods started postgres, and when I tried to open the database anyway, to double check, it returns a slightly different error message than before.
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"?
[1]+ Exit 2 postgres -D /usr/local/pgsql/data > logfile 2>&
How to start PostgreSQL server on Mac OS X? seems related, but has some gaps. Just running initdb wasn't enough, and I don't seem to have a .conf.sample. Do I just need to create a new .conf from scratch or what?
For reference I'm running Snow Leopard, I originally tried to manually instal psql, but ended up installing brew then brew installing psql.
Have you tried doing a find?
sudo find / -name postgresql*
With a freshly installed version of Postgres 9.2 via yum repository on Centos 6, how do you run postgres as a different user when it is configured to run as 'postgres:postgres' (u:g) out of the box?
In addition to AndrewPK's explanation, I'd like to note that you can also start new PostgreSQL instances as any user by stopping and disabling the system Pg service, then using:
initdb -D /path/to/data/directory
pg_ctl start -D /path/to/data/directory
This won't auto-start the server on boot, though. For that you must integrate into your init system. On CentOS 6 a simple System V-style init script in /etc/init.d/ and a suitable symlink into /etc/rc3.d/ or /etc/rc3.d/ (depending on default runlevel) is sufficient.
If running more than one instance at a time they must be on different ports. Change the port directive in postgresql.conf in the datadir or set it on startup with pg_ctl -o "-p 5433" .... You may also need to override the unix_socket_directories if your user doesn't have write permission to the default socket directory.
pg_ctl
initdb
This is only for a fresh installation (as it pertained to my situation) as it involves blowing away the data dir.
The steps I took to resolve this issue while utilizing the packaged startup scripts for a fresh installation:
Remove the postgres data dir /var/lib/pgsql/9.2/data if you've already gone through the initdb process with the postgres user:group configured as default.
Modify the startup script (/etc/init.d/postgresql-9.2) to replace all instances of postgres:postgres with NEWUSER:NEWGROUP.
Modify the startup script to replace all instances of postgres in any $SU -l postgres lines with the NEWUSER.
run /etc/init.d/postgres initdb to regenerate the cluster using the new username
Make sure any logs created are owned by the new user or remove old logs if error on initdb (the configuration file in my case was found in /var/lib/pgsql/9.2/data/postgresql.conf).
Startup postgres and it should now be running under the new user/group.
I understand this might not be what other people are looking for if they have existing postgres db's and want to restart the server to run as a different user/group combo - this was not my case, and I didn't see an answer posted anywhere for a 'fresh' install utilizing the pre-packaged startup scripts.