I'm having some trouble getting postgresql working with systemd. The unit
originally would fail to start, until I realised that the script it uses to
start assume that the variables in /etc/conf.d/postgresql will be defined, and
in my setup they were commented out.

Once I'd uncommented them, the unit starts OK, and I can connect using pgsql.
However, there is no domain socket created at /tmp/.s.PGSQL.5432, which is
clearly not right. It means that phpPgAdmin is broken in its default
configuration.

I'd be surprised if noone else had encountered this, although I can't find any
obvious chatter online. Has someone determined the best way to fix?

Paul

On Tuesday 04 Sep 2012 16:10:21 you wrote:
> I'm having some trouble getting postgresql working with systemd. The unit
> originally would fail to start, until I realised that the script it uses to
> start assume that the variables in /etc/conf.d/postgresql will be defined,
> and in my setup they were commented out.
>
> Once I'd uncommented them, the unit starts OK, and I can connect using
> pgsql. However, there is no domain socket created at /tmp/.s.PGSQL.5432,
> which is clearly not right. It means that phpPgAdmin is broken in its
> default configuration.

Forget this bit. It's been a long day and I was an idiot: I didn't twig that
the socket starts with a dot and would not appear in a simple "ls". The
socket is being created fine, but phpPgAdmin still won't connect, even though
pgsql is fine, and I'm not sure why.

Paul

On Tuesday 04 Sep 2012 16:13:32 you wrote:
> The socket is being created fine, but phpPgAdmin still won't connect, even
> though pgsql is fine, and I'm not sure why.

I now think this is something to do with php-fpm.service having
PrivateTmp=true, but I haven't had any luck even after commenting out this
line and doing "systemctl daemon-reload" and restarting the daemon.

Paul

On Tue, Sep 4, 2012 at 6:30 PM, Paul Gideon Dann <pdgiddie@gmail.com> wrote:

> On Tuesday 04 Sep 2012 16:13:32 you wrote:
> > The socket is being created fine, but phpPgAdmin still won't connect,
> even
> > though pgsql is fine, and I'm not sure why.
>
> I now think this is something to do with php-fpm.service having
> PrivateTmp=true, but I haven't had any luck even after commenting out this
> line and doing "systemctl daemon-reload" and restarting the daemon.
>
> Paul
>


If you try it with sysvinit, does it work correctly?

On Tuesday 04 Sep 2012 18:36:04 D. Can Celasun wrote:
> On Tue, Sep 4, 2012 at 6:30 PM, Paul Gideon Dann <pdgiddie@gmail.com> wrote:
> > On Tuesday 04 Sep 2012 16:13:32 you wrote:
> > > The socket is being created fine, but phpPgAdmin still won't connect,
> >
> > even
> >
> > > though pgsql is fine, and I'm not sure why.
> >
> > I now think this is something to do with php-fpm.service having
> > PrivateTmp=true, but I haven't had any luck even after commenting out this
> > line and doing "systemctl daemon-reload" and restarting the daemon.
> >
> > Paul
>
> If you try it with sysvinit, does it work correctly?

Yeah, it doesn't work with /etc/rc.d/php-fpm either. Obviously something else
has broken in a recent update. Php-fpm also seems to be randomly segfaulting
on start (and sometimes starting fine):

:: Checking configuration [DONE]
:: Starting php-fpm [BUSY]
/etc/rc.d/php-fpm: line 55: 31083 Segmentation fault /usr/sbin/php-fpm

Rebuilding php-fpm from ABS doesn't make that go away.

Paul

On 05/09/12, Paul Gideon Dann wrote:

| :: Checking configuration [DONE]
| :: Starting php-fpm [BUSY]
| /etc/rc.d/php-fpm: line 55: 31083 Segmentation fault /usr/sbin/php-fpm
|
| Rebuilding php-fpm from ABS doesn't make that go away.
|
| Paul

Arch bug:
https://bugs.archlinux.org/task/31166

Upstream (PHP) bug:
https://bugs.php.net/bug.php?id=62886

--
Simon Perry (aka Pezz)

On Thursday 06 Sep 2012 01:58:29 Simon Perry wrote:
> On 05/09/12, Paul Gideon Dann wrote:
> | :: Checking configuration [DONE]
> | :: Starting php-fpm [BUSY]
> |
> | /etc/rc.d/php-fpm: line 55: 31083 Segmentation fault
> | /usr/sbin/php-fpm
> |
> | Rebuilding php-fpm from ABS doesn't make that go away.
> |
> | Paul
>
> Arch bug:
> https://bugs.archlinux.org/task/31166
>
> Upstream (PHP) bug:
> https://bugs.php.net/bug.php?id=62886

Yeah, I spotted that too, and this is probably related, but I'm not getting a
hang. After the segfault, php-fpm actually continues to work (maybe just the
worker dies and a new one is spawned?), and phpMyAdmin works with MySQL just
fine, but phpPgAdmin doesn't, even though Postgres is clearly operating
correctly.

Very strange...(Penny Lane...)

Paul

On Thursday 06 Sep 2012 09:37:51 you wrote:
> Yeah, I spotted that too, and this is probably related, but I'm not getting
> a hang. After the segfault, php-fpm actually continues to work (maybe just
> the worker dies and a new one is spawned?), and phpMyAdmin works with MySQL
> just fine, but phpPgAdmin doesn't, even though Postgres is clearly
> operating correctly.
>
> Very strange...(Penny Lane...)

It's been a tough week (evidenced by the fact that I posted to the list in
frustration), and it turns out I wasn't careful enough with my basic checks.

The problem was exactly what I thought it was originally: the systemd unit file
for php-fpm must have PrivateTmp=false, or it won't see the Postgres socket.

Bug tracker ticket created: https://bugs.archlinux.org/task/31436

All the other failures were because Firefox was remembering the wrong login
details for phpPgAdmin. (Schoolboy error!)

Simple fix: create /etc/systemd/system/php-fpm.service with the following
contents:

-------
.include /usr/lib/systemd/system/php-fpm.service

[Service]
PrivateTmp=false
-------

This makes things work for me. The segfaulting still happens, but isn't a
blocker for me, as the service works fine despite it.

Paul