Thread: Docker image not running on IPv6-disabled systems
Hi, thanks for the great job!
* Description:
I have docker installed in updated Void Linux and use "ipv6.disable=1"
in the kernel cmdline to hard-disable IPv6 support systemwide. In
these conditions, the container fails to start with the following log
messages:
$LOG$
NOTE: Configuring authentication for SERVER mode.
[2019-01-15 20:21:22 +0000] [1] [INFO] Starting gunicorn 19.8.1
[2019-01-15 20:21:22 +0000] [1] [ERROR] Retrying in 1 second.
[2019-01-15 20:21:23 +0000] [1] [ERROR] Retrying in 1 second.
[2019-01-15 20:21:24 +0000] [1] [ERROR] Retrying in 1 second.
[2019-01-15 20:21:25 +0000] [1] [ERROR] Retrying in 1 second.
[2019-01-15 20:21:26 +0000] [1] [ERROR] Retrying in 1 second.
[2019-01-15 20:21:27 +0000] [1] [ERROR] Can't connect to ('::', 80)
$LOG$
After that it fails and will fail again if restarted.
* Problem:
So I find it's the "exec gunicorn" lines near the end of the
entrypoint script ("/entrypoint.sh"). It's specifying "[::]" in the
address part of the argument to the "--bind" option to "gunicorn".
* Solution:
It would be enough to change the argument of the "--bind" option to
"gunicorn" from "[::]:${PGADMIN_LISTEN_PORT:-443}" to
"0.0.0.0:${PGADMIN_LISTEN_PORT:-443}" and from
"[::]:${PGADMIN_LISTEN_PORT:-80}" to
"0.0.0.0:${PGADMIN_LISTEN_PORT:-80}".
* Workaround:
As a workaround, I make a new image from the following Dockerfile:
$Dockerfile$
FROM dpage/pgadmin4:latest
RUN sed -i 's/\[::\]/0.0.0.0/' /entrypoint.sh
# This is just candy:
SHELL ["/bin/sh"]
$Dockerfile$
* Notes:
I also tested removing the aforementioned kernel cmdline option and
the original image works like a charm. So this might only affect IPv6
hard-disabled systems.
Thanks again.
Here's the patch, sorry for the bad manners.
Attachment
Hi On Wed, Jan 16, 2019 at 12:41 PM Diego Augusto Molina <diegoaugustomolina@gmail.com> wrote: > > Here's the patch, sorry for the bad manners. That effectively reverts the fix committed to resolve this doesn't it? https://redmine.postgresql.org/issues/3392 Maybe the way to go is to expose the bind address (or some options to control it) in variables that can be set at launch time, leaving the default as-is. Thoughts? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi, Dave On 1/22/19, Dave Page <dpage@pgadmin.org> wrote: > Hi > > On Wed, Jan 16, 2019 at 12:41 PM Diego Augusto Molina > <diegoaugustomolina@gmail.com> wrote: >> >> Here's the patch, sorry for the bad manners. > > That effectively reverts the fix committed to resolve this doesn't it? > https://redmine.postgresql.org/issues/3392 Yeah, it really does. > > Maybe the way to go is to expose the bind address (or some options to > control it) in variables that can be set at launch time, leaving the > default as-is. > > Thoughts? Sounds like the way to go. There goes the new humble patch for the "/entrypoint.sh", which runs just fine. The new environment variable is named PGADMIN_LISTEN_ADDRESS and defaults to "[::]". Tested with the following Dockerfile: $Dockerfile$ FROM dpage/pgadmin4:latest RUN sed -i 's/\[::\]/${PGADMIN_BIND_ADDRESS:-[::]}/' /entrypoint.sh # This is just candy but could be added for ease of use in debugging: SHELL ["/bin/sh"] $Dockerfile$ Thanks a lot! > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Attachment
Thanks - patch applied (with a doc update). On Tue, Jan 29, 2019 at 6:41 AM Diego Augusto Molina <diegoaugustomolina@gmail.com> wrote: > > Hi, Dave > > On 1/22/19, Dave Page <dpage@pgadmin.org> wrote: > > Hi > > > > On Wed, Jan 16, 2019 at 12:41 PM Diego Augusto Molina > > <diegoaugustomolina@gmail.com> wrote: > >> > >> Here's the patch, sorry for the bad manners. > > > > That effectively reverts the fix committed to resolve this doesn't it? > > https://redmine.postgresql.org/issues/3392 > > Yeah, it really does. > > > > > Maybe the way to go is to expose the bind address (or some options to > > control it) in variables that can be set at launch time, leaving the > > default as-is. > > > > Thoughts? > > Sounds like the way to go. There goes the new humble patch for the > "/entrypoint.sh", which runs just fine. The new environment variable > is named PGADMIN_LISTEN_ADDRESS and defaults to "[::]". Tested with > the following Dockerfile: > > $Dockerfile$ > FROM dpage/pgadmin4:latest > > RUN sed -i 's/\[::\]/${PGADMIN_BIND_ADDRESS:-[::]}/' /entrypoint.sh > > # This is just candy but could be added for ease of use in debugging: > SHELL ["/bin/sh"] > > $Dockerfile$ > > > > Thanks a lot! > > > > > -- > > Dave Page > > Blog: http://pgsnake.blogspot.com > > Twitter: @pgsnake > > > > EnterpriseDB UK: http://www.enterprisedb.com > > The Enterprise PostgreSQL Company > > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
For some reason when I had troubles with IPv4 and IPv6 and pgadmin I first came across this post. For others who face the same: actually the issue has already been solved, have a look at the enviroment variable PGADMIN_LISTEN_ADDRESS - more information at https://www.pgadmin.org/docs/pgadmin4/latest/container_deployment.html#environment-variables -- Sent from: https://www.postgresql-archive.org/PostgreSQL-pgadmin-support-f2191615.html