1

I am running Postgres v10.3 through Docker (docker-compose, specifically). It is not turning back on. I get the following error message when I try to turn it on:

postgres           | pg_ctl: another server might be running; trying to start server anyway
postgres           | waiting for server to start....2018-05-15 12:37:07.552 UTC [22] LOG:  listening on IPv4 address "127.0.0.1", port 5432
postgres           | 2018-05-15 12:37:07.552 UTC [22] LOG:  could not bind IPv6 address "::1": Address not available
postgres           | 2018-05-15 12:37:07.552 UTC [22] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
postgres           | 2018-05-15 12:37:07.558 UTC [22] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres           | 2018-05-15 12:37:07.804 UTC [23] LOG:  database system was interrupted while in recovery at 2018-05-15 12:35:58 UTC
postgres           | 2018-05-15 12:37:07.804 UTC [23] HINT:  This probably means that some data is corrupted and you will have to use the last backup for recovery.
postgres           | .........2018-05-15 12:37:17.735 UTC [23] LOG:  database system was not properly shut down; automatic recovery in progress
postgres           | .2018-05-15 12:37:17.935 UTC [23] LOG:  redo starts at 1/5E964BA8
postgres           | pg_ctl: server did not start in time
postgres           | ................................................. stopped waiting

I may have shut down the database as I was writing to it, which is the only thing I can think of that would have caused this. I do not have a backup which is why I'd like to restore what I've already done (except for the table that I was writing to when I shut down).

Things I've tried:

  • Restarting the docker container and clearing out the cache (docker system prune -f)

  • Remove the postmaster.pid file and restarting

    • This gives me a could not open file "postmaster.pid": No such file or directory error and generates a postmaster.pid file which then allows me to get back to my original error
  • Start by checking what is currently listening on ::1 port 5432... – Patrick Mevzek May 15 '18 at 15:00
  • sudo lsof -i :5432 prints nothing, so i think that means nothing is currently listening on that port – zebrainatree May 15 '18 at 15:03
2

Those messages are unrelated. The first one will show up every time you start postgresql if your machine is not configured to use IPv6. You can just ignore it if you don't care about IPv6.

The other one is a bit more complex. 'system was not properly shut down' means it was interrupted without being given a chance to do a checkpoint and shut down. 'database system was interrupted while in recovery' means that it had been interrupted before, and was then interrupted again before it was able to clean up from the previous interruption, and is now trying to clean up from both of those previous interruptions.

The 'stopped waiting' means the pg_ctl call in your startup script is not patient enough to for the recovery to happen (which seems to me to be a poor decision to make in a startup script). But then the issue is, what then? Sometimes when pg_ctl runs out of patience, it just exits nicely and lets the recovery proceed in the background. Sometimes it clubs the recovery process over the head. Which of these it does seems to be pretty unpredictable (to me, anyway) it depends on your OS and OS version, and how your start-up script is written, and maybe what logging options you have configured.

Based on the log file show posted, it is likely that on your system pg_ctl clubs the recovery process over the head once it runs out of patience. So you shutdown the system uncleanly when it was in the middle of something hectic. Restarting it will take a lot of time, because it has to clean up whatever it was in the middle of. pg_ctl ran out of patience and killed it (this part was not in your posted logfile snippet). Then pg_ctl ran out of patience again and killed (this part is in your snipped).

Your start-up script should probably pass a large timeout value to the -t flag of pg_ctl, to make it patient.

  • How to set a a large timeout value to the -t flag of pg_ctl? – IntoTheDeep Jun 17 '18 at 8:43
  • I don't know, it depends on your start-up script. Does the one you use come with docker? Does it come from some package manager? Did you roll your own? – jjanes Jun 17 '18 at 14:05
  • this is the issue I had dba.stackexchange.com/questions/209845/… – IntoTheDeep Jun 17 '18 at 14:06
  • Well, it looks like it is going to be somewhere in /etc/init.d/postgresql, then. Or something that that calls in turn. The problem with all the dockerized and virtualized stuff is that as soon as something goes wrong, everyone can only shrug and point the finger at someone else. Might want to "fgrep -r pg_ctl /etc/" – jjanes Jun 17 '18 at 14:43
  • Sorry, I do not understand anything from your comment – IntoTheDeep Jun 17 '18 at 18:27
0

I got it to work by entering the postgres docker container via bash, then su postgres, and finally postgres --single -D /var/lib/postgresql/data/pgdata -P -d 5

It took about 15 minute from there, but it worked!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.