Red Hat Bugzilla – Bug 825448
Daemons using PrivateTmp can no longer talk to postgres
Last modified: 2017-08-11 10:12:44 EDT
Description of problem:
Daemons (such as Apache) which use the new PrivateTmp feature in F17 can no longer talk to postgres via a unix socket.
Fedora should probably do what Ubuntu does, and place the unix domain sockets in /run/postgresql or something rather than /tmp where anything which has a private tmp can't see them.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run any web application that wants to talk to postgres
2. Watch it fail to connect, saying /tmp/.s.PGSQL.5432 not found
The difficulty here is that the location of the socket is effectively part of the client protocol; moving it is not different in kind from, say, deciding that the postmaster is going to listen on some port other than 5432. We could teach libpq to look in a different place but there are other client-side implementations of the protocol besides libpq.
After some discussion with Honza Horak I think that we might be able to mostly circumvent that objection by teaching postgres to listen on two sockets, one in /tmp for compatibility purposes and one in some other place (probably the same as what Debian uses, which I think is /var/run/pgsql). The compatibility socket would not be useful for daemons using PrivateTmp, but it seems like we could define that use-case as outside the range of what we're trying to be compatible with.
The upstream code is not currently designed to handle more than one Unix socket, but it does cheerfully handle multiple TCP listen addresses; so I think it likely won't be too hard to get it to handle multiple socket files too.
Ah I hadn't realised there were other clients besides libpq... Presumably Debian must be patching any other clients to use their alternative location.
Listening on both sounds like a reasonable plan anyway.
Ubuntu (and presumably Debian) are using /var/run/postgresql so I guess that is probably the best choice.
Just a regular user here.
In /var/lib/pgsql/data/postgresql.conf I tried setting:
unix_socket_directory = '/var/run/postgresql'
/bin/systemctl start postgresql.service
Job failed. See system journal and 'systemctl status' for details.
Maybe that was too simple-minded.
That will be because /var/run/postgresql doesn't exist and postgres probably doesn't try to create it so you will need to do so yourself.
The real problem though is that the client library won't know to look there for the socket, so even if the server starts it probably won't help.
Thanks for the reply Tom.
While you are working on Postgres. Here's an error I get in dmesg:
[ 49.746169] postgres (881): /proc/881/oom_adj is deprecated, please use /proc/881/oom_score_adj instead.
on Fedora 17.
*** Bug 801506 has been marked as a duplicate of this bug. ***
Thanks for getting a fix for this. I'll test the new version tonight to see how it works.
As of postgresql-9.1.4-5.fc17, the postmaster will create a socket in /var/run/postgresql as well as /tmp, and the former is where libpq will try to open connections by default. So this should Just Work now for daemons that use libpq to talk to postgresql. I'm not sure whether any of the affected daemons use some other code, but if they do, they'll probably need updates to use sockets in /var/run/postgresql instead of /tmp.
Note that TCP-based clients (such as the Java JDBC driver) are unaffected by all this.
postgresql-9.1.4-5.fc17 has been submitted as an update for Fedora 17.
I tried out postgresql-9.1.4-5.fc17, removed my special config for httpd.service and things juts worked. Thanks.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing postgresql-9.1.4-5.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
postgresql-9.1.5-1.fc17 has been submitted as an update for Fedora 17.
postgresql-9.1.5-1.fc16 has been submitted as an update for Fedora 16.
postgresql-9.1.5-1.fc18 has been submitted as an update for Fedora 18.
postgresql-9.1.5-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.