Can't access PostgreSQL after crash restart, reports dbus error

I was running Postgresql database v9.6 and I rebooted, but now it will not start. Nothing seems to work. Any idea?

I am trying to run my Django Server:

django.db.utils.OperationalError: could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?

I tried to following commands:

$ sudo /etc/init.d/postgresql restart * Restarting PostgreSQL 9.6 database server * Failed to issue method call: Unit failed to load: No such file or directory. See system logs and 'systemctl status ' for details.
$ sudo service postgresql start * Starting PostgreSQL 9.6 database server * Failed to issue method call: Unit failed to load: No such file or directory. See system logs and 'systemctl status ' for details. [fail]
(env) dominic@dom-Inspiron-7559:~/Desktop/Project $ systemctl status Failed to issue method call: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/postgresql_409_2e6_2dmain_2eservice
$ pg_config --version
PostgreSQL 11.2 (Ubuntu 11.2-1.pgdg14.04+1)
$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.6 main 5432 down postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
$ sudo pg_ctlcluster 9.6 main start
Failed to issue method call: Unit failed to load: No such file or directory. See system logs and 'systemctl status ' for details.
$ sudo systemctl daemon-reload

EDIT:

$ ps uxa|grep postgres
dominic 13786 0.0 0.0 15952 2304 pts/0 S+ 17:18 0:00 grep --color=auto postgres

/var/log/postgresql$ sudo vim postgresql-9.6-main.log.1

2019-03-16 16:15:26.224 EDT [7265] modadmin@mod LOG: could not receive data from client: Connection reset by peer
2019-03-17 15:08:10.290 EDT [12791] modadmin@mod LOG: could not receive data from client: Connection reset by peer
2019-03-17 15:16:39.060 EDT [17891] modadmin@mod LOG: could not receive data from client: Connection reset by peer

I don't see anything from today..?

1 Answer

Dbus is an inter-process communication (IPC) solution used widely in Linux distributions. Also systemd uses it. However, it is independent from PostgreSQL.

The systemctl status commands shows an error message related most likely to that the systemctl command, as a command-line app, can't contact your systemd. Systemd is the top-top daemon of your system, managing all background services, including PostgreSQL.

So you have at least two, independent problems. Note, such events are rare on Linux, most likely you had bad luck. I hope, you have some type of backup if your Postgresql had important data in it.

Probably fixing your PostgreSQL is the more important. What is well visible, that your PostgreSQL didn't start (if it had, your django could have connected it). You can manually, and more directly check it if a ps uxa|grep postgres doesn't give any feasible result.

Check the end of your postgresql log, which is most likely in /var/log/postgresql.log. It is possible, that your database is corrupt. If it is so, you are struck - for postgresql, simply no low-level database recovery tool was ever developed. You need to have always good backups. There are some tricky way with what you can recover a little bit of your data, but these are well over the limits of this post.

Always have at least one backup from everything what is important on your system. It shouldn't be an useful, high-level, effective solution, but it should exist. For example, a daily pg_dump yourDjangoDb|pxz -9ve - >/var/backups/djangopg.xz is pretty okay for a development workstation.

_{Extend your question with the end of your postgresql.log.}

About the dbus, to know if the service is still running, execute the ps uxa|grep dbus-daemon command. If it doesn't run, you have a problem. If it runs, you can Dbus doesn't have any really important persistent data in itself, so you will be able to do more "direct" ways to make it working again. If it doesn't run, then there is some communication problem, which is most likely related to some unix sockets in /run. Anyways a strace systemctl status dbus.service could help a lot.