Bug 825448 - Daemons using PrivateTmp can no longer talk to postgres
Daemons using PrivateTmp can no longer talk to postgres
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
: 801506 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-05-26 06:42 EDT by Tom Hughes
Modified: 2017-08-11 10:12 EDT (History)
6 users (show)

See Also:
Fixed In Version: postgresql-9.1.4-5.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-25 22:53:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Hughes 2012-05-26 06:42:23 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
Actual results:

Connection fails.

Expected results:

Connection works.
Comment 1 Tom Lane 2012-06-05 12:13:34 EDT
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.
Comment 2 Tom Hughes 2012-06-05 12:20:25 EDT
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.
Comment 3 David McKellar 2012-06-11 10:37:51 EDT
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.
Comment 4 Tom Hughes 2012-06-11 10:49:09 EDT
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.
Comment 5 David McKellar 2012-06-11 11:09:38 EDT
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.
Comment 6 Tom Lane 2012-08-08 22:21:03 EDT
*** Bug 801506 has been marked as a duplicate of this bug. ***
Comment 7 Bruno Wolff III 2012-08-13 13:41:00 EDT
Thanks for getting a fix for this. I'll test the new version tonight to see how it works.
Comment 8 Tom Lane 2012-08-13 13:57:10 EDT
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.
Comment 9 Fedora Update System 2012-08-13 14:00:52 EDT
postgresql-9.1.4-5.fc17 has been submitted as an update for Fedora 17.
Comment 10 Bruno Wolff III 2012-08-13 16:07:17 EDT
I tried out postgresql-9.1.4-5.fc17, removed my special config for httpd.service and things juts worked. Thanks.
Comment 11 Fedora Update System 2012-08-14 05:21:20 EDT
Package postgresql-9.1.4-5.fc17:
* 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).
Comment 12 Fedora Update System 2012-08-17 13:16:41 EDT
postgresql-9.1.5-1.fc17 has been submitted as an update for Fedora 17.
Comment 13 Fedora Update System 2012-08-17 13:17:01 EDT
postgresql-9.1.5-1.fc16 has been submitted as an update for Fedora 16.
Comment 14 Fedora Update System 2012-08-17 13:17:22 EDT
postgresql-9.1.5-1.fc18 has been submitted as an update for Fedora 18.
Comment 15 Fedora Update System 2012-08-25 20:26:05 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.