Postgresql server doesn't start
This is an idiosyncrasy of the systemd integration of PostgreSQL in Xenial.
The postgresql service unit installed by the postgresql-common package is just a dummy service which causes the actual service [email protected] to be started via a dependency. You can see that dependency by running the command
systemctl list-dependencies postgresql
That dependency is not permanent, but generated during system boot by the systemd generator /lib/systemd/system-generators/postgresql-generator
which also comes with the postgresql-common package. The generator checks whether the startup mode in the file /etc/postgresql/9.6/main/start.conf
is set to auto
, and if so, sets up the dependency that subsequently causes instance 9.6-main to be started.
(More precisely, it checks all configuration subdirectories /etc/postgresql/*/*
and will create dependencies for all instances that are configured for automatic startup, but in a default installation there will be just the one instance.)
Due to the limitations of systemd generators (see man systemd.generator
) this process may fail, causing the dependencies to be absent after a reboot.
Systemd will then start only the dummy service, writing
systemd[1]: Starting PostgreSQL RDBMS...
systemd[1]: Started PostgreSQL RDBMS.
to the log but otherwise doing nothing. Attempting to start the service manually by
systemctl start postgresql
will just reproduce that result. Running the command
systemctl daemon-reload
manually as root will re-run the generator and in most cases fix the problem until the next reboot.
To solve the problem permanently you'll have to find the reason why the generator fails during boot. Possible causes can be found in the systemd.generator manpage. In my case it was the PostgreSQL config file /etc/postgresql/9.6/main/postgresql.conf
which was symlinked to a different filesystem that wasn't available yet when the generator ran early during boot. postgresql-generator
checks the existence of that file even though it doesn't otherwise need it.
Extending on the answer of Tilman, but not enough Kudos to comment...
If you do not need the service to be called postgresql and do not care about the wrapper dummy service, it should work to just to control the real service directly. It's name is : postgresql@$version-$cluster.service In your case it should be postgresql-9.5-main in short. Like to start
systemctl start [email protected]
and to stop:
systemctl stop [email protected]
Status will also give you much better and accurate information than on the auto generated wrapper service.
systemctl status [email protected]
For 9.6 it looks like this:
● [email protected] - PostgreSQL Cluster 9.6-main
Loaded: loaded (/lib/systemd/system/[email protected]; disabled; vendor preset: enabled)
Active: active (running) since Wed 2017-09-13 00:41:50 CEST; 7h ago
Process: 10235 ExecStop=/usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast %i stop (code=exited, status=2)
Process: 10676 ExecStart=postgresql@%i --skip-systemctl-redirect %i start (code=exited, status=0/SUCCESS)
Main PID: 10683 (postgres)
CGroup: /system.slice/system-postgresql.slice/[email protected]
├─10683 /usr/lib/postgresql/9.6/bin/postgres -D /var/lib/postgresql/9.6/main -c config_file=/etc/postgresql/9.6/main/postgresql.conf
├─10685 postgres: 9.6/main: checkpointer process
├─10686 postgres: 9.6/main: writer process
├─10748 postgres: 9.6/main: wal writer process
├─10749 postgres: 9.6/main: autovacuum launcher process
├─10750 postgres: 9.6/main: archiver process last was 000000020000000000000082
├─10751 postgres: 9.6/main: stats collector process
In my case this was related to incorrectly configured locales.
I've found the solution in this dba.stackexchange.com answer:
- Use
sudo dpkg-reconfigure locales
to generate the necessary locales - Drop the existing database cluster via
sudo pg_dropcluster 9.5 main
(this will erase all the data in the cluster!) - Re-create the cluster via
sudo pg_createcluster 9.5 main --start
- Restart PostgreSQL via
sudo service postgresql restart