docker-pgbouncer: Failure to generate userlist.txt

Steps to reproduce:

docker run --rm \
    -e DB_USER=****** \
    -e DB_PASSWORD=******** \
    -e DB_HOST=******** \
    -e DB_NAME=postgres \
    -p 5432:5432 \
    edoburu/pgbouncer

Gives the following error:

2021-01-23 16:08:45.798 UTC [1] ERROR could not open auth_file /etc/pgbouncer/userlist.txt: No such file or directory

Subsequently, connecting to the database fails:

2021-01-23 16:09:06.757 UTC [1] LOG C-0x7f04932a30f0: (nodb)/(nouser)@127.0.0.1:46564 no such user: ******

Shouldn’t that be done automatically?

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 18
  • Comments: 27 (3 by maintainers)

Most upvoted comments

@cheungpat The new code was pushed on the same tags which created existing containers to fail as well.

I made a Dockerfile from the sha of the working one and pushed it to my own docker repository.

# Dockerfile
FROM edoburu/pgbouncer@sha256:e173802088fdbd6626a2e9ca66d01c4be029ca04710cca73ae818efa1f4d7dd7

It appears recent changes caused userlist.txt to be absent, and the entrypoint.sh do not create the file if it is missing

https://github.com/edoburu/docker-pgbouncer/commit/d33ec7c6416f5dc9d5947caab1c3f46a8bd16528

Any workaround that places userlist.txt under /etc/pgbouncer would work, I changed my run command to touch /etc/pgbouncer/userlist.txt before running the entrypoint script.

@esalter I think the images are indeed properly tagged using semver, and you should still be getting 1.14.0 if you pulled edoburu/pgbouncer:1.14.0.

EDIT: See #35 for proposal for immutable tags

I appreciate all the work maintainers do but in the future please tag releases using semver. It would have helped us as we were targeting 1.14.0, not latest, so I would not have expected that to update.

When I try to mount a volume with an empty userlist.txt file I get the following error: /entrypoint.sh: line 49: can't create /etc/pgbouncer/userlist.txt: Permission denied

@grizim-power Ordinarily, yes, but not feasible for a project like edoburu/docker-pgbouncer that provides container images to a corresponding pgbouncer release. Take the current release for example; if it is buggy or contains security vulnerabilities, then we will need to push to the same image tag anyway. The fix could also end up creating a new bug for another set of users as well. So, IMO, the correct approach is to change the versioning scheme/practice, as proposed in #35, so that we can maintain immutability of the image tags while providing (1) versioned releases and (2) releases mapped to upstream pgbouncer versions.

IMO, even if we have a bug or security vulnerabilities - we should not push a new image with the same tag. Override existing image losing the point of versioning.