Comment 4 for bug 1744098

I'm seeing exactly this issue on a devstack setup (master from last week) that makes a xenial guest. I note that the systemd unit file: /lib/systemd/system/postgresql@.service has:

PIDFile=/run/postgresql/%i.pid # note %i = 9.6/main

So 'service postgresql start' and all variants thereof end up hanging forever awaiting the wrong pidfile, and the guest ends up in a state where the service thinks postgres is down but it is actually up.

I think this is happening because the service discovery code in Trove checks for upstart, sysv and systemd in that order. So on xenial it finds a postgresql file in /etc/init.d and decides we are sysv - so does not apply trove/integration/scripts/files/elements/ubuntu-xenial-postgresql/install.d/31-fix-init-script to amend the pifile in the systemd unit. I'm thinking that the detection should be in upstart, systemd then sysv order.