We install the latest postgres 11 using apt-get with a process that has been working smoothly for many months (see below). However, a few hours ago it began failing because the default postgresql.conf suddenly changed from port 5432 to 5433. I confirmed on another linux machine outside of travis that this is not what gets installed normally. Any reason for this stealth change or was it made in error?
Yeah, it’s a private build so I can’t link to it, but the only line that changed during the installation process is the one showing the port below (previously it was identical but said 5432). I verified by putting it in debug mode that that postgresql.conf installed now contains 5433 as the default port instead of 5432. A default port of 5432 is what gets installed when I follow this exact same procedure on an ubuntu box external to travis.
Failing
selecting default shared_buffers ... 128MB
selecting default timezone ... UTC
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctlcluster 11 main start
Ver Cluster Port Status Owner Data directory Log file
11 main 5433 down postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
update-alternatives: using /usr/share/postgresql/11/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode
Processing triggers for libc-bin (2.23-0ubuntu11) ...
Passing
selecting default shared_buffers ... 128MB
selecting default timezone ... UTC
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctlcluster 11 main start
Ver Cluster Port Status Owner Data directory Log file
11 main 5432 down postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
update-alternatives: using /usr/share/postgresql/11/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode
Processing triggers for libc-bin (2.23-0ubuntu11) ...
And then when I try to execute psql without specifying a port (because it expects the normal default of 5432):
Failing
$ psql -c 'create database my_test;' -U postgres
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
The command "psql -c 'create database my_test;' -U postgres" failed and exited with 2 during .
I can read the private logs for support purposes. The log excerpts are incomplete and could be misleading. If you do not wish to communicate that here, please email support@travis-ci.com instead. Thanks.
My PosgresSQL 11 stopped working today too and I am still debugging what is wrong.
Feb 25 16:54:50 travis-job-52e8b9bc-0564-4590-a9d7-60388fb379d0 systemd[1]: Starting PostgreSQL Cluster 11-main...
Feb 25 16:54:50 travis-job-52e8b9bc-0564-4590-a9d7-60388fb379d0 postgresql@11-main[6338]: Error: /var/ramfs/postgresql/11/main is not accessible or does not exist
Feb 25 16:54:50 travis-job-52e8b9bc-0564-4590-a9d7-60388fb379d0 systemd[1]: postgresql@11-main.service: Can't open PID file /run/postgresql/11-main.pid (yet?) after start: No such file or directory
Feb 25 16:54:50 travis-job-52e8b9bc-0564-4590-a9d7-60388fb379d0 systemd[1]: postgresql@11-main.service: Failed with result 'protocol'.
Feb 25 16:54:50 travis-job-52e8b9bc-0564-4590-a9d7-60388fb379d0 systemd[1]: Failed to start PostgreSQL Cluster 11-main.
Well, if github would start working, it would help The problem appears to be isolated to the 11.7-2 release on bionic, xenial is fine. Will keep after it and hope github starts working again!
Thanks I did submit one, but it sounds like the issue is the new image changed the default port. I’m guessing that will not be reverted, so I will try to use one of the workarounds others have given.