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?

My file userlist.txt have only admin_users and stats_users but not have user of database destination.

I can not login using the user of database destination, show this error:
pooler error: password authentication failed

When I added user of database destination in userlist.txt login was successfully.

But I not want add user of database destination in userlist.txt.

pgbouncer.ini:

[databases]
db1 = host=db1.aws.com port=5432

[pgbouncer]
admin_users = pgbouncer
application_name_add_host = 1
auth_file = /etc/pgbouncer/userlist.txt
auth_query = SELECT uname, phash from user_lookup($1)
auth_type = md5
auth_user = pgbouncer
default_pool_size = 100
ignore_startup_parameters = extra_float_digits
listen_addr = 0.0.0.0
listen_port = 5432
log_connections = 1
log_disconnections = 1
log_pooler_errors = 1
logfile = /dev/stderr
max_client_conn = 10000
min_pool_size = 2
pidfile = /run/pgbouncer/pgbouncer.pid
pool_mode = transaction
server_reset_query = ""
stats_users = monitoring
unix_socket_dir = /tmp
user = postgres

userlist.txt:

"pgbouncer" "Pass-plain-text"
"monitoring" "Pass-plain-text"

Can anyone help me?

Hi,

I just spend a few hours looking for an issue in the setup. The error in the logs was:
"WARNING TLS handshake error: handshake failed: error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error"

However, the main reason was that Postgresql server was on version 11, I was using PgBouncer docker image with tag 1.12.0.
After switching to tag 1.11.0 everything works as expected

Please, add proper log message or allow compatibility for older Postgresql versions.

Hello,
I am trying to deploy a psql and pgbouncer services from the following yml file:

version: "3.7"
services:
  psql:
    image: postgres
    restart: always
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: xxxx
      PGDATA: /data/postgres
    volumes:
       - /home/debian/postgres:/data/postgres
    networks:
      - direct_web
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
         - node.hostname == first
  pgbouncer:
    image: edoburu/pgbouncer
    environment:
       - DB_USER=postgres
       - DB_PASSWORD=xxxx
       - DB_HOST=psql
       - DB_NAME=test
       - POOL_MODE=transaction
       - ADMIN_USERS=postgres,user
    ports:
      - "5432:5432"
    networks:
      - direct_web
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
         - node.hostname == first
    depends_on:
      - psql
networks:
  direct_web:
    name: direct_web
    external: true

I get this following error in pgbouncer logs :

Create pgbouncer config in /etc/pgbouncer
################## Auto generated ##################
[databases]
test= host=psql port=5432 user=postgres

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 5432
unix_socket_dir =
user = postgres
auth_file = /etc/pgbouncer/userlist.txt
auth_type = md5
pool_mode = transaction
ignore_startup_parameters = extra_float_digits

# Log settings
admin_users = postgres,user

# Connection sanity checks, timeouts

# TLS settings

# Dangerous timeouts
 ################## end file ##################
2021-04-20 13:35:59.761 UTC [1] ERROR could not open auth_file /etc/pgbouncer/userlist.txt: No such file or directory
2021-04-20 13:35:59.766 UTC [1] LOG kernel file descriptor limit: 1048576 (hard: 1048576); max_client_conn: 100, max expected fd use: 132
 Starting /usr/bin/pgbouncer /etc/pgbouncer/pgbouncer.ini...
2021-04-20 13:35:59.768 UTC [1] LOG listening on 0.0.0.0:5432
2021-04-20 13:35:59.768 UTC [1] LOG process up: PgBouncer 1.15.0, libevent 2.1.12-stable (epoll), adns: udns 0.4, tls: OpenSSL 1.1.1i  8 Dec 2020

1.21.0 supports prepared statements and would be immensely useful to add it!

In the postgres docker containers there is the option to use the following to set something sensitive like passwords:

POSTGRES_PASSWORD_FILE: /run/secrets/db-password-file

This reads the password from a text-file, a 'secret'. See also https://www.docker.com/blog/how-to-use-the-postgres-docker-official-image/

The password never leaves the server this way and doesn't end up in a git repo somewhere as opposed to using this:

DB_PASSWORD: dbpassword

Is there a way to this using this container? Are you open here to a pull request adding this feature? Or am I missing some other way to configure the password?

Does edoburu/pgbouncer support for scram-sha-256?

I tried changing the AUTH_TYPE to scram-sha-256 but it does not work.

Example for a django connect string:

DATABASE_URL=postgres://foo:b@[email protected]:5432/mydb

If the password contains '@' character, the parsing cuts on the first @ and includes the rest of the password/@ in the hostname.

Context

As seen in #33, some of us were caught off guard by a recent commit that made changes to the container's behaviour while keeping the same image tag. Issue #33 discusses the actual problem that caused the pgbouncer to crash but this issue focuses on preventing such changes from making its way into our production systems even though we've pinned the image tags.

Proposal

Currently, the project already provides semver-compliant image tags mapped to the specific pgbouncer versions (e.g. 1.15.0, 1.14.0). However, since edoburu/pgbouncer is a project that provides container images for the upstream pgbouncer project, changes (sometimes breaking) may be occasionally required.

One way we can do this is to roll our own semver-compliant versioning scheme but this can be confusing to new users (thinking that these are the corresponding pgbouncer versions) and they do not allow us to track a specific pgbouncer version, say 1.14.0 for example.

As such, I'm proposing to use a modified, 4-component versioning format:

X.Y.Z.V

• where X.Y.Z is the regular semver of the pgbouncer version
• where .V is the incremental version used by edoburu/pgbouncer for any changes to the Dockerfile.

For example, whenever a change is made to the Dockerfile or the entrypoint script, we will bump the last component of the version:

• 1.15.0.1 -> 1.15.0.2
• 1.14.0.1 -> 1.13.0.2
• 1.13.0.1 -> 1.13.0.2
• 1.12.0.1 -> 1.12.0.2

Using this proposed versioning scheme, at least we can ensure that all edoburu/pgbouncer image tags are immutable.

Limitations

• The proposed versioning scheme does deviate from being semver-compliant
• Immutable image tags are already possible but the current image tags give a false sense of immutability

Hi,

thanks for working on this project. I would like to ask you if you are planning to publish new image with pgbouncer v1.22 included?

Regards,
Pavel

Since you are building pgbouncer from source, would it be possible to also produce images for arm processors?
Something along the lines of how timescaledb does it: https://github.com/timescale/timescaledb-docker/blob/master/.github/workflows/docker-image.yml#L33

I guess that would require to push image building to Github Action vs using DockerHub.

Since there is only one pool entry in [databases] section defined there is no way to configure multiple connection pools. The example from pgBouncer documentation as follows:

[databases]
; foodb over Unix socket
foodb =

; redirect bardb to bazdb on localhost
bardb = host=127.0.0.1 dbname=bazdb

; access to destination database will go with single user
forcedb = host=127.0.0.1 port=300 user=baz password=foo client_encoding=UNICODE datestyle=ISO

I'm using standard docker image built from the original Dockerfile. There is no way I can connect to the pgbouncer console. User postgres is defined in the pgbouncer.ini but does not end-up in the auth_file with a default password. Please add it in the auth_file at the generation time.
postgres:postgres or any other default password. Add it in the docs as well please.
Great work otherwise!

We have been running the 1.11.0 image without any issues for a while, but now started to get the following errors:

Starting /usr/bin/pgbouncer /etc/pgbouncer/pgbouncer.ini...
Error loading shared library libssl.so.48: No such file or directory (needed by /usr/bin/pgbouncer)
Error loading shared library libcrypto.so.46: No such file or directory (needed by /usr/bin/pgbouncer)

I've noticed that the images on DockerHub were upgrade two days ago as part of #32. Could this be related?

Hi we created helm chart using latest docker image of edoburu/pgbouncer .when we ran security (blackduck ) scan on this image, It is giving following security issues for below components:

GNU Library 2.17 : CVE-2012-4412,CVE-2014-5119, CVE-2014-4043,CVE-2015-8779, CVE-2015-8778,CVE-2015-1472, CVE-2014-9984,CVE-2015-5277,CVE-2013-4237

GNU Core Utilities8.22 CVE-2014-9471

any plan to fix this in near term?

Regards,
Amit

Hi there,

Thanks for maintaining this great project - fitting my exact needs :-)
However, I cannot find any way to connect to the admin console..

Could you be a bit more specific on instructions to access the admin console ?

The only way to access admin console is to add an admin user to the DB and add it's credentials to userlist.txt ? Can it be another username than admin ?
Then the connection needs to be with postgres user and using admin password specified in the userlist.txt ?
Could not make it work like this..

Also, using kubernetes, is it a good practice to add some REPLICAS ?

Thanks,
Tim

Could it be possible to include pg_isready in the image? This is with the purpose of having Kubernetes liveness and readiness tests running.

hello all,
Is there a support for pgbouncer docker image with groups in Azure Active Directory. We have these AAD groups mapped to Postgres database roles in our Azure PostgresSQL database. Currently, members of these roles are able to connect to Postgres using AAD auth tokens as passwords. How can we map this experience with pgBouncer?

Hello,
When I send many requests at the same time (1000) I get response times of about 1 seconds for each request, what are the means to improve my performance?
This response time does not come from the performance of the host machine.

Hi,

thank you for the great work. I am currently running few deployments of this image on kubernetes and I think it could benefit from having a way to enable unix sockets. It would make it easier to run sidecar containers such as a prometheus exporter. or other Currently to run this kind of sidecar, the credentials have to be passed to both containers in the pod. Having a unix socket in an emptyDir volume would make it very easy to access to the pgbouncer db from a sidecar.

The current default of disabling unix sockets is fine and doesn't have to be changed.

version: '3'
services:
timescale:
image: timescale/timescaledb:latest-pg11
environment:
POSTGRES_DB: test
POSTGRES_USER: postgres
POSTGRES_PASSWORD: test
TIMESCALEDB_TELEMETRY: 'off'
ports:
- 5432:5432
pgbouncer:
build:
context: .
dockerfile: docker-pgbouncer/Dockerfile
depends_on:
- timescale
links:
- timescale
environment:
DB_NAME: test
DB_USER: postgres
DB_PASSWORD: test
DB_HOST: timescale
POOL_MODE: session
SERVER_RESET_QUERY: "DISCARD ALL"
MAX_CLIENT_CONN: 10

docker run -d --name timescaledb -p 5432:5432 -e POSTGRES_PASSWORD=password -e POSTGRES_DB=dev -e POSTGRES_USER=test -e TIMESCALEDB_TELEMETRY='off' timescale/timescaledb:latest-pg11

current base image have lot of security issues - see trivy scan result. All of them can be easy fixed by change base image to maintained by me security patched alpine FROM lapierre/alpine:3. I constantly improve security vulnerabilities and upload an image to the docker hub

trivy edoburu/pgbouncer
2021-04-02T08:41:03.514+0200	WARN	You should avoid using the :latest tag as it is cached. You need to specify '--clear-cache' option when :latest image is changed
2021-04-02T08:41:03.530+0200	INFO	Need to update DB
2021-04-02T08:41:03.530+0200	INFO	Downloading DB...
20.65 MiB / 20.65 MiB [------------------------------------------------------------------------------------] 100.00% 11.73 MiB p/s 2s
2021-04-02T08:41:10.458+0200	INFO	Detecting Alpine vulnerabilities...
2021-04-02T08:41:10.460+0200	INFO	Trivy skips scanning programming language libraries because no supported file was detected

edoburu/pgbouncer (alpine 3.13.0)
=================================
Total: 32 (UNKNOWN: 0, LOW: 5, MEDIUM: 8, HIGH: 19, CRITICAL: 0)

+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
|      LIBRARY      | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |                 TITLE                 |
+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| busybox           | CVE-2021-28831   | HIGH     | 1.32.1-r0         | 1.32.1-r4     | busybox: invalid free or segmentation |
|                   |                  |          |                   |               | fault via malformed gzip data         |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-28831 |
+-------------------+------------------+          +-------------------+---------------+---------------------------------------+
| libcrypto1.1      | CVE-2021-23840   |          | 1.1.1i-r0         | 1.1.1j-r0     | openssl: integer                      |
|                   |                  |          |                   |               | overflow in CipherUpdate              |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23840 |
+                   +------------------+          +                   +---------------+---------------------------------------+
|                   | CVE-2021-3450    |          |                   | 1.1.1k-r0     | openssl: CA certificate check         |
|                   |                  |          |                   |               | bypass with X509_V_FLAG_X509_STRICT   |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3450  |
+                   +------------------+----------+                   +---------------+---------------------------------------+
|                   | CVE-2021-23841   | MEDIUM   |                   | 1.1.1j-r0     | openssl: NULL pointer dereference     |
|                   |                  |          |                   |               | in X509_issuer_and_serial_hash()      |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23841 |
+                   +------------------+          +                   +---------------+---------------------------------------+
|                   | CVE-2021-3449    |          |                   | 1.1.1k-r0     | openssl: NULL pointer dereference     |
|                   |                  |          |                   |               | in signature_algorithms processing    |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3449  |
+                   +------------------+----------+                   +---------------+---------------------------------------+
|                   | CVE-2021-23839   | LOW      |                   | 1.1.1j-r0     | openssl: incorrect SSLv2              |
|                   |                  |          |                   |               | rollback protection                   |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23839 |
+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| libldap           | CVE-2020-36221   | HIGH     | 2.4.56-r0         | 2.4.57-r0     | openldap: Integer underflow           |
|                   |                  |          |                   |               | in serialNumberAndIssuerCheck         |
|                   |                  |          |                   |               | in schema_init.c                      |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36221 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36222   |          |                   |               | openldap: Assertion failure in        |
|                   |                  |          |                   |               | slapd in the saslAuthzTo validation   |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36222 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36223   |          |                   |               | openldap: Out-of-bounds               |
|                   |                  |          |                   |               | read in Values Return Filter          |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36223 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36224   |          |                   |               | openldap: Invalid pointer free        |
|                   |                  |          |                   |               | in the saslAuthzTo processing         |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36224 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36225   |          |                   |               | openldap: Double free in              |
|                   |                  |          |                   |               | the saslAuthzTo processing            |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36225 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36226   |          |                   |               | openldap: Denial of service           |
|                   |                  |          |                   |               | via length miscalculation             |
|                   |                  |          |                   |               | in slap_parse_user                    |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36226 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36227   |          |                   |               | openldap: Infinite loop in slapd with |
|                   |                  |          |                   |               | the cancel_extop Cancel operation     |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36227 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36228   |          |                   |               | openldap: Integer underflow           |
|                   |                  |          |                   |               | in issuerAndThisUpdateCheck           |
|                   |                  |          |                   |               | in schema_init.c                      |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36228 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36229   |          |                   |               | openldap: Type confusion              |
|                   |                  |          |                   |               | in ad_keystring in ad.c               |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36229 |
+                   +------------------+          +                   +               +---------------------------------------+
|                   | CVE-2020-36230   |          |                   |               | openldap: Assertion failure in        |
|                   |                  |          |                   |               | ber_next_element in decode.c          |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-36230 |
+                   +------------------+          +                   +---------------+---------------------------------------+
|                   | CVE-2021-27212   |          |                   | 2.4.57-r1     | openldap: Assertion                   |
|                   |                  |          |                   |               | failure in slapd in the               |
|                   |                  |          |                   |               | issuerAndThisUpdateCheck function     |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-27212 |
+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| libpq             | CVE-2021-20229   | MEDIUM   | 13.1-r1           | 13.2-r0       | postgresql: single-column SELECT      |
|                   |                  |          |                   |               | privilege enables reading all columns |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-20229 |
+                   +------------------+----------+                   +               +---------------------------------------+
|                   | CVE-2021-3393    | LOW      |                   |               | postgresql: Partition                 |
|                   |                  |          |                   |               | constraint violation errors           |
|                   |                  |          |                   |               | leak values of denied columns         |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3393  |
+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| libssl1.1         | CVE-2021-23840   | HIGH     | 1.1.1i-r0         | 1.1.1j-r0     | openssl: integer                      |
|                   |                  |          |                   |               | overflow in CipherUpdate              |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23840 |
+                   +------------------+          +                   +---------------+---------------------------------------+
|                   | CVE-2021-3450    |          |                   | 1.1.1k-r0     | openssl: CA certificate check         |
|                   |                  |          |                   |               | bypass with X509_V_FLAG_X509_STRICT   |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3450  |
+                   +------------------+----------+                   +---------------+---------------------------------------+
|                   | CVE-2021-23841   | MEDIUM   |                   | 1.1.1j-r0     | openssl: NULL pointer dereference     |
|                   |                  |          |                   |               | in X509_issuer_and_serial_hash()      |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23841 |
+                   +------------------+          +                   +---------------+---------------------------------------+
|                   | CVE-2021-3449    |          |                   | 1.1.1k-r0     | openssl: NULL pointer dereference     |
|                   |                  |          |                   |               | in signature_algorithms processing    |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3449  |
+                   +------------------+----------+                   +---------------+---------------------------------------+
|                   | CVE-2021-23839   | LOW      |                   | 1.1.1j-r0     | openssl: incorrect SSLv2              |
|                   |                  |          |                   |               | rollback protection                   |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23839 |
+-------------------+------------------+----------+                   +               +---------------------------------------+
| openssl-dev       | CVE-2021-23840   | HIGH     |                   |               | openssl: integer                      |
|                   |                  |          |                   |               | overflow in CipherUpdate              |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23840 |
+                   +------------------+          +                   +---------------+---------------------------------------+
|                   | CVE-2021-3450    |          |                   | 1.1.1k-r0     | openssl: CA certificate check         |
|                   |                  |          |                   |               | bypass with X509_V_FLAG_X509_STRICT   |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3450  |
+                   +------------------+----------+                   +---------------+---------------------------------------+
|                   | CVE-2021-23841   | MEDIUM   |                   | 1.1.1j-r0     | openssl: NULL pointer dereference     |
|                   |                  |          |                   |               | in X509_issuer_and_serial_hash()      |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23841 |
+                   +------------------+          +                   +---------------+---------------------------------------+
|                   | CVE-2021-3449    |          |                   | 1.1.1k-r0     | openssl: NULL pointer dereference     |
|                   |                  |          |                   |               | in signature_algorithms processing    |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3449  |
+                   +------------------+----------+                   +---------------+---------------------------------------+
|                   | CVE-2021-23839   | LOW      |                   | 1.1.1j-r0     | openssl: incorrect SSLv2              |
|                   |                  |          |                   |               | rollback protection                   |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-23839 |
+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| postgresql-client | CVE-2021-20229   | MEDIUM   | 13.1-r1           | 13.2-r0       | postgresql: single-column SELECT      |
|                   |                  |          |                   |               | privilege enables reading all columns |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-20229 |
+                   +------------------+----------+                   +               +---------------------------------------+
|                   | CVE-2021-3393    | LOW      |                   |               | postgresql: Partition                 |
|                   |                  |          |                   |               | constraint violation errors           |
|                   |                  |          |                   |               | leak values of denied columns         |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-3393  |
+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| ssl_client        | CVE-2021-28831   | HIGH     | 1.32.1-r0         | 1.32.1-r4     | busybox: invalid free or segmentation |
|                   |                  |          |                   |               | fault via malformed gzip data         |
|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2021-28831 |
+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+

Scan result for pgbouncer on patched Alpine

trivy lapierre/pgbouncer:1.14.0
2021-04-02T08:43:01.748+0200	INFO	Detecting Alpine vulnerabilities...
2021-04-02T08:43:01.750+0200	INFO	Trivy skips scanning programming language libraries because no supported file was detected

lapierre/pgbouncer:1.14.0 (alpine 3.13.3)
=========================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

With

docker run --link ... edoburu/pgbouncer:VERSION

I get

...@(bad-af):0 closing because: server dns lookup failed (age=0)

for any versions >= 1.9.0. With 1.8.1 it works.

pgbouncer 1.16.1 is now out

https://www.pgbouncer.org/2021/11/pgbouncer-1-16-1

I just run the example/docker-compose which running postgresql-14

docker ps -a
CONTAINER ID   IMAGE                       COMMAND                  CREATED          STATUS                      PORTS                                                                                                  NAMES
99811313e2bd   edoburu/pgbouncer           "/entrypoint.sh /usr…"   15 minutes ago   Up 15 minutes               0.0.0.0:5432->5432/tcp, :::5432->5432/tcp                                                              docker-compose_pgbouncer_1
78f6f2663b31   postgres:14                 "docker-entrypoint.s…"   15 minutes ago   Up 15 minutes               5432/tcp                                                                                               docker-compose_db_1

but I can not connect to postgres

sql postgres://dbuser:hbZkzny5xrvVH@localhost/test
psql: error: ERROR:  pgbouncer cannot connect to server
chchang@dc03:~/docker/docker-pgbouncer/examples/docker-compose$ 

and docker logs

022-03-24 04:11:27.606 UTC [1] LOG C-0x7f202e049100: test/[email protected]:48860 closing because: pgbouncer cannot connect to server (age=0s)
2022-03-24 04:11:27.606 UTC [1] WARNING C-0x7f202e049100: test/[email protected]:48860 pooler error: pgbouncer cannot connect to server
2022-03-24 04:11:27.607 UTC [1] LOG S-0x7f202e042120: test/[email protected]:5432 new connection to server (from 192.168.192.3:36570)
2022-03-24 04:11:27.608 UTC [1] ERROR S-0x7f202e042120: test/[email protected]:5432 cannot do SCRAM authentication: wrong password type
2022-03-24 04:11:27.608 UTC [1] LOG S-0x7f202e042120: test/[email protected]:5432 closing because: failed to answer authreq (age=0s)

any suggestions ???

Thanks for your work on this docker container! Could you add a license? Without a license, I understand it defaults to an implicit copyright which would theoretically allow you to assert copyright and demand that anyone stop using the code in this repo: https://blog.codinghorror.com/pick-a-license-any-license

I am completely new to docker, I might be doing some small mistake though

root@docker:/# docker run --name=pgbouncer_2 -e DB_USER=postgres -e DB_PASSWORD=test -e DB_HOST=192.168.0.102 -e DB_NAME=postgres -v pgbouncer.ini:/etc/pgbouncer/pgbouncer.ini -p 5432:5432 edoburu/pgbouncer
Wrote authentication credentials to /etc/pgbouncer/userlist.txt
Create pgbouncer config in /etc/pgbouncer
grep: /etc/pgbouncer/userlist.txt: No such file or directory
/entrypoint.sh: line 58: can't create /etc/pgbouncer/pgbouncer.ini: Is a directory

When I start with only username and password it works, however I want this to take multiple users hence I was trying to run this with external configuration file option.

Pgbouncer to version 1.18.0
Alpine to version 1.17.0

Steps to reproduce

1. Define DATABASE_URL env. variable with the password containing * sign , for example

DATABASE_URL=postgres://user:1*[email protected]:5432/db

Resulting pgbouncer.ini file will contain wrong connection parameters.

This part of the entrypoint.sh script does not work as expected in this case

  # extract the host -- updated
  hostport=`echo $url | sed -e s,$userpass@,,g | cut -d/ -f1`

Started pgbouncer container with below command

docker run -d -p 6432:5432 --name pgbouncer -v /var/log/pgbouncer:/var/log/pgbouncer -v /etc/pgbouncer/:/etc/pgbouncer -v /etc/pgbouncer/pgbouncer.ini:/etc/pgbouncer/pgbouncer.ini pgbouncer

The container start and keeps running, when i tried to connect database using below command

psql -hlocalhost -Upgbouncer -p6432 -dpostgres -W

Prompt for password entry, upon password entry the container crashed with error in logs pgbouncer: Cannot get system entropy

I am trying to specify DB_NAME in the secret so that pgbouncer pod can use it.
Here's my secret

apiVersion: v1
data:
  DB_HOST: cG9zdGdyZXMtcG9zdGdyZXNxbC5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsCg==
  DB_PASSWORD: #base64 encoded password here
  DB_USER: cG9zdGdyZXMK
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"DB_HOST":"cG9zdGdyZXMuZGVmYXVsdA==","DB_PASSWORD":"cGFzc3dvcmQ=","DB_USER":"dXNlcm5hbWU="},"kind":"Secret","metadata":{"annotations":{},"creationTimestamp":null,"name":"pgbouncer-example-env","namespace":"default"}}
  creationTimestamp: "2020-01-17T09:52:50Z"
  name: pgbouncer-example-env
  namespace: default
  resourceVersion: "628099"
  selfLink: /api/v1/namespaces/default/secrets/pgbouncer-example-env
  uid: 72550c32-3494-434d-af65-30766414ccfd
type: Opaque

I delete the pgbouncer pod so that it would pick up the new config but the pod goes into CrashLoopBackOff

grep: /etc/pgbouncer/userlist.txt: No such file or directory
Wrote authentication credentials to /etc/pgbouncer/userlist.txt
Create pgbouncer config in /etc/pgbouncer
################## Auto generated ##################
[databases]
postgres
 = host=postgres-postgresql.default.svc.cluster.local
 port=5432 user=postgres


[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 5432
unix_socket_dir =
user = postgres
auth_file = /etc/pgbouncer/userlist.txt
auth_type = md5
pool_mode = session
ignore_startup_parameters = extra_float_digits

# Log settings
admin_users = postgres

# Connection sanity checks, timeouts
server_reset_query = DISCARD ALL

# TLS settings

# Dangerous timeouts
################## end file ##################
Starting /usr/bin/pgbouncer /etc/pgbouncer/pgbouncer.ini...
2020-01-20 11:46:12.144 1 ERROR syntax error in configuration (/etc/pgbouncer/pgbouncer.ini:3), stopping loading
2020-01-20 11:46:12.144 1 FATAL cannot load config file

I also ran the image as standalone docker container. It works fine as a container and writes the config properly.

I am not sure if this is related but I noticed two extra environment variables were present in kubernetes pod which were being used by entrypoint.sh but were not present in standalone docker container.

SERVER_RESET_QUERY=DISCARD ALL
POOL_MODE=session

I think I might be missing something silly but I have tried different ways but could not get this working.

Hi all,

I have a small point of confusion when comparing the Docker Compose examples for Documentation and the Kubernetes example of Documentation.

See here: https://github.com/edoburu/docker-pgbouncer/blob/master/examples/docker-compose/docker-compose.yml

• In this example, you are asking for the Database Name.

In comparison: https://github.com/edoburu/docker-pgbouncer/blob/master/examples/kubernetes/singleuser/pgbouncer-example-env.yml

• In this example, you are not asking for the Database Name.

Is there a reason for this - for instance, is the DB Name handled when our application (like Django in which we specify the DB_Name) actually connects to PGBouncer rather than specifying it beforehand? Or should we be adding that ENV on-top of your suggestions?

Thanks,
Omar

Hi Edoburu people, first thank you for the great pg-bouncer image, works awesome.
It's less of an issue and more like a question/suggestion. Do you people have any recommendations how much memory/processor resources some should provide in kubernetes setup for this image in terms limits/requests?

Docker Version: 4.11.1
PgBouncer Version: 1.17.0
DataBase: Timescale 2.7.2-pg14

This happens every time I turn on the pc and docker starts by itself at start up, while if I do docker run or docker-compose up ... never gives that error of FATAL pidfile exists, another instance running?.

Why this happens?

Log File
2022-08-10 08:30:21.491 UTC [1] LOG kernel file descriptor limit: 1048576 (hard: 1048576); max_client_conn: 150, max expected fd use: 212 2022-08-10 08:30:21.492 UTC [1] LOG listening on 172.20.0.9:6432 2022-08-10 08:30:21.492 UTC [1] LOG listening on 127.0.0.1:6432 2022-08-10 08:30:21.492 UTC [1] WARNING cannot listen on 127.0.0.1:6432: bind(): Address in use 2022-08-10 08:30:21.492 UTC [1] WARNING cannot listen on [::1]:6432: bind(): Address not available 2022-08-10 08:30:21.492 UTC [1] LOG listening on unix:/tmp/.s.PGSQL.6432 2022-08-10 08:30:21.492 UTC [1] LOG process up: PgBouncer 1.17.0, libevent 2.1.12-stable (epoll), adns: udns 0.4, tls: OpenSSL 1.1.1q  5 Jul 2022 2022-08-10 08:30:21.880 UTC [1] LOG C-0x7fa96ffa80c0: DataAnalyser/[email protected]:59670 login attempt: db=DataAnalyser user=postgres tls=no 2022-08-10 08:30:21.902 UTC [1] LOG S-0x7fa96ff520f0: DataAnalyser/[email protected]:5432 new connection to server (from 172.20.0.9:36646) 2022-08-10 08:30:21.909 UTC [1] LOG S-0x7fa96ff520f0: DataAnalyser/[email protected]:5432 SSL established: TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=prime256v1 2022-08-10 08:30:23.440 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54102 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:24.192 UTC [1] LOG C-0x7fa96ffa8520: DataAnalyser/[email protected]:55784 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:25.810 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55796 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:29.723 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54102 closing because: client close request (age=6s) 2022-08-10 08:30:30.825 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54160 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.615 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55796 closing because: client close request (age=6s) 2022-08-10 08:30:32.618 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55842 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.662 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55842 closing because: client close request (age=0s) 2022-08-10 08:30:32.664 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55844 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.756 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55844 closing because: client close request (age=0s) 2022-08-10 08:30:32.759 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55846 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.769 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55846 closing because: client close request (age=0s) 2022-08-10 08:30:32.773 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55848 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.782 UTC [1] LOG S-0x7fa96ff52320: DataAnalyser/[email protected]:5432 new connection to server (from 172.20.0.9:36728) 2022-08-10 08:30:32.786 UTC [1] LOG S-0x7fa96ff52320: DataAnalyser/[email protected]:5432 SSL established: TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=prime256v1 2022-08-10 08:30:32.811 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55848 closing because: client close request (age=0s) 2022-08-10 08:30:32.813 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55852 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.824 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55852 closing because: client close request (age=0s) 2022-08-10 08:30:32.827 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55854 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.837 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55854 closing because: client close request (age=0s) 2022-08-10 08:30:32.840 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55856 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.899 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55856 closing because: client close request (age=0s) 2022-08-10 08:30:32.902 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55860 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.921 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55860 closing because: client close request (age=0s) 2022-08-10 08:30:32.924 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55862 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:32.929 UTC [1] LOG C-0x7fa96ffa8520: DataAnalyser/[email protected]:55784 closing because: client close request (age=8s) 2022-08-10 08:30:33.627 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54160 closing because: client close request (age=2s) 2022-08-10 08:30:35.384 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54194 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:36.464 UTC [1] LOG C-0x7fa96ffa8520: DataAnalyser/[email protected]:55878 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:36.498 UTC [1] LOG C-0x7fa96ffa8520: DataAnalyser/[email protected]:55878 closing because: client close request (age=0s) 2022-08-10 08:30:37.940 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55862 closing because: client close request (age=5s) 2022-08-10 08:30:37.943 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55886 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:38.216 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54194 closing because: client close request (age=2s) 2022-08-10 08:30:39.948 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54212 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:40.130 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54212 closing because: client close request (age=0s) 2022-08-10 08:30:41.245 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54218 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:42.959 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55886 closing because: client close request (age=5s) 2022-08-10 08:30:42.962 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55900 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:44.415 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54218 closing because: client close request (age=3s) 2022-08-10 08:30:45.940 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54226 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:47.977 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55900 closing because: client close request (age=5s) 2022-08-10 08:30:47.980 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55908 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:49.122 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54226 closing because: client close request (age=3s) 2022-08-10 08:30:51.073 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54240 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:52.994 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55908 closing because: client close request (age=5s) 2022-08-10 08:30:52.997 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55922 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:53.649 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54240 closing because: client close request (age=2s) 2022-08-10 08:30:55.209 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54248 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:58.012 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55922 closing because: client close request (age=5s) 2022-08-10 08:30:58.018 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55930 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:30:58.596 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54248 closing because: client close request (age=3s) 2022-08-10 08:31:00.242 UTC [1] LOG C-0x7fa96ffa82f0: DataAnalyser/[email protected]:54256 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:03.043 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55930 closing because: client close request (age=5s) 2022-08-10 08:31:03.046 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55938 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:08.063 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55938 closing because: client close request (age=5s) 2022-08-10 08:31:08.065 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55940 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:13.081 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55940 closing because: client close request (age=5s) 2022-08-10 08:31:13.084 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55942 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:18.094 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55942 closing because: client close request (age=5s) 2022-08-10 08:31:18.097 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55944 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:21.485 UTC [1] LOG stats: 7 xacts/s, 7 queries/s, in 4619 B/s, out 3767 B/s, xact 4093 us, query 3823 us, wait 660 us 2022-08-10 08:31:23.109 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55944 closing because: client close request (age=5s) 2022-08-10 08:31:23.111 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55946 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:28.124 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55946 closing because: client close request (age=5s) 2022-08-10 08:31:28.126 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55948 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:33.142 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55948 closing because: client close request (age=5s) 2022-08-10 08:31:33.145 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55954 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:38.161 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55954 closing because: client close request (age=5s) 2022-08-10 08:31:38.164 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55956 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:43.178 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55956 closing because: client close request (age=5s) 2022-08-10 08:31:43.182 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55966 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:46.497 UTC [1] LOG C-0x7fa96ffa8520: DataAnalyser/[email protected]:56018 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:46.549 UTC [1] LOG C-0x7fa96ffa8980: DataAnalyser/[email protected]:54344 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:46.563 UTC [1] LOG C-0x7fa96ffa8bb0: DataAnalyser/[email protected]:56022 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:46.584 UTC [1] LOG S-0x7fa96ff52550: DataAnalyser/[email protected]:5432 new connection to server (from 172.20.0.9:36902) 2022-08-10 08:31:46.591 UTC [1] LOG S-0x7fa96ff52550: DataAnalyser/[email protected]:5432 SSL established: TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=prime256v1 2022-08-10 08:31:46.607 UTC [1] LOG C-0x7fa96ffa8de0: DataAnalyser/[email protected]:54350 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:46.615 UTC [1] LOG C-0x7fa96ffa9010: DataAnalyser/[email protected]:56028 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:46.686 UTC [1] LOG C-0x7fa96ffa9240: DataAnalyser/[email protected]:56034 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:48.210 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:55966 closing because: client close request (age=5s) 2022-08-10 08:31:48.214 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56044 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:50.794 UTC [1] LOG S-0x7fa96ff52780: DataAnalyser/[email protected]:5432 new connection to server (from 172.20.0.9:36950) 2022-08-10 08:31:50.804 UTC [1] LOG S-0x7fa96ff52780: DataAnalyser/[email protected]:5432 SSL established: TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=prime256v1 2022-08-10 08:31:53.233 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56044 closing because: client close request (age=5s) 2022-08-10 08:31:53.238 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56094 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:31:58.268 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56094 closing because: client close request (age=5s) 2022-08-10 08:31:58.270 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56096 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:03.283 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56096 closing because: client close request (age=5s) 2022-08-10 08:32:03.285 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56112 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:08.300 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56112 closing because: client close request (age=5s) 2022-08-10 08:32:08.303 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56114 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:13.319 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56114 closing because: client close request (age=5s) 2022-08-10 08:32:13.321 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56118 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:18.333 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56118 closing because: client close request (age=5s) 2022-08-10 08:32:19.660 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56126 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:21.485 UTC [1] LOG stats: 2 xacts/s, 2 queries/s, in 2229 B/s, out 336 B/s, xact 13777 us, query 13777 us, wait 447 us 2022-08-10 08:32:24.676 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56126 closing because: client close request (age=5s) 2022-08-10 08:32:24.679 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56128 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:29.695 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56128 closing because: client close request (age=5s) 2022-08-10 08:32:29.698 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56158 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:34.717 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56158 closing because: client close request (age=5s) 2022-08-10 08:32:34.719 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56168 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:39.734 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56168 closing because: client close request (age=5s) 2022-08-10 08:32:39.738 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56184 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:44.755 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56184 closing because: client close request (age=5s) 2022-08-10 08:32:44.758 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56206 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:49.774 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56206 closing because: client close request (age=5s) 2022-08-10 08:32:49.777 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56226 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:32:54.794 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56226 closing because: client close request (age=5s) 2022-08-10 08:32:54.797 UTC [1] LOG C-0x7fa96ffa8750: DataAnalyser/[email protected]:56242 login attempt: db=DataAnalyser user=postgres tls=TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384/ECDH=X25519 2022-08-10 08:35:48.337 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:35:49.171 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:35:49.844 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:35:50.602 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:35:51.779 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:35:53.691 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:35:57.184 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:36:03.871 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:36:16.930 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:36:42.825 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:37:34.311 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:38:34.663 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:39:34.999 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:40:35.369 UTC [1] FATAL pidfile exists, another instance running? 2022-08-10 08:41:35.687 UTC [1] FATAL pidfile exists, another instance running?

I'm not sure if it was intentional but when you moved to version 1.19.1 of PgBouncer you changed the tag format to start with a v. This means that the listing in https://github.com/edoburu/docker-pgbouncer#available-tags is incorrect. Instead of having a format like 1.19.1-p0 it now has a prefix of v which makes it v1.19.1-p0.

I simply wanted to point this out in case it wasn't intentional and also recommend updating the available tags list to reflect the change in tag format.

docker pull edoburu/pgbouncer:1.19.1-p0
Error response from daemon: manifest for edoburu/pgbouncer:1.19.1-p0 not found: manifest unknown: manifest unknown
docker pull edoburu/pgbouncer:v1.19.1-p0
v1.19.1-p0: Pulling from edoburu/pgbouncer
f56be85fc22e: Pull complete
9b80169bab20: Pull complete
ca672000f9ad: Pull complete
Digest: sha256:c8ed57880d65d46dc285356de971b2a4693e07480d5987ab97bf57eaa79e3644
Status: Downloaded newer image for edoburu/pgbouncer:v1.19.1-p0
docker.io/edoburu/pgbouncer:v1.19.1-p0

Hi,

I am trying to build the image from the docker file provided to understand it better. If I run the container after building, it throws me this error
pgbouncer_1 | standard_init_linux.go:219: exec user process caused: no such file or directory

However, it runs fine if i pull the edoburu/docker-pgbouncer image. Am I missing something?

I encounterd error: Permission denined with file: /var/log/pgbouncer/pgbouncer.log

I found out that in Dockerfile, you forgot to chown this file, pls fix it

Thank

I start pgbouncer with command:

docker run --rm \
    -e DATABASE_URL="postgres://postgres:[email protected]/mydb" \
    -p 5432:5432 \
    edoburu/pgbouncer

When I try to connect to database thrue pgbouncer, I get crashed pgbouncer with error:
pgbouncer: Cannot get system entropy

Hello there.

I'm trying to connect to a Heroku database and I'm having this error when using this docker image, while connecting to it:
pgbouncer_1 | 2019-12-20 15:22:01.750 1 LOG: dbname/user@(bad-af):0 closing because: server dns lookup failed (age=0)

Currently, pgbouncer:1.8.1 works fine and all of the following are facing the same issue.

I've git bisected the issue to this PR: #8

I'm assuming the issue is with udns vs c-ares which is what was used previously.

Would a environment variable, describing the dns package to be used/compiled with, be an acceptable solution? I'm happy to work on a PR with that changes, if you agree.

Would it be possible to get an example of divergent credentials for PGBOUNCER and POSTGRES (using more recent versions of Postgres)? Using the example with homogenous credentials appears to work, but customization isn't intuitive -- especially for situations where multiple databases exist. I keep receiving password authentication failed and I need the ability to differentiate between what credentials are meaningful where (without visually parsing the docker compose file). Additionally, your documentation makes it look like the userlist.txt formula is md5 + ((md5 of password) + username), but per generate-userlist it's actually md5 + (md5 of (password+username)).

Anyway, definitely appreciate the work done here, but significantly more differentiable, and explicit, examples would be nice. Also, perhaps a pgbouncer.ini-only example.

Hi, we'd interested in using pgbouncer 1.11.0.

Are you open to contribuitions/PRs in this regard? He've tested it in our own fork and it works fine. Thanks !

In PGBouncer version 1.21.0 the max_prepared_statements setting was added. In order to benefit from prepared statements, one must change this setting.

I'll try to implement this tonight. Created PR #87

When I set SERVER_RESET_QUERY: '', it doesn't work.

The container orchestration configuration is as follows:

  pgbouncer01:
    << : *default_cfg
    image: registry.inventec/hub/edoburu/pgbouncer:1.14
    hostname: pgbouncer01
    ports:
      - target: 5432
        published: 5493
        protocol: tcp
        mode: host
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /opt/patroni/config/userlist.txt:/etc/pgbouncer/userlist.txt:ro
    environment:
      DB_HOST: pg1201
      POOL_MODE: transaction
      SERVER_RESET_QUERY: ""
      MAX_CLIENT_CONN: 1000
      IGNORE_STARTUP_PARAMETERS: 'extra_float_digits,search_path,lc_monetary'
    deploy:
      restart_policy:
        condition: on-failure
      placement:
        constraints: 
          - node.labels.alias == bdc06.infra.dev.tj.itc.inventec
      resources:
        limits:
          cpus: "2"
          memory: 1g

Containing a * char in a password causes issues in line 28 of the entrypoint script: https://github.com/edoburu/docker-pgbouncer/blob/master/entrypoint.sh#L28

the userpass is not properly parsed out, and instead the entire string after the postgres:// prefix is interpreted as the port

Hey there,

Looking at one of my old implementations of this, I have the following in the my entry point so we can put certs in environment variables. Fancy adding something like this to yours?

if [[ -z "${PGBOUNCER_DATABASE_SSL_CLIENT_CERT}" ]]; then
    echo "► No SSL Client Cert Found"
  else
    echo "${PGBOUNCER_DATABASE_SSL_CLIENT_CERT}" | base64 -d > /tmp/client-cert.pem
    echo "► SSL Client Cert Found.  Writing to /tmp/client-cert.pem"
  fi

  if [[ -z "${PGBOUNCER_DATABASE_SSL_CLIENT_KEY}" ]]; then
    echo "► No SSL Client Key Found"
  else
    echo "${PGBOUNCER_DATABASE_SSL_CLIENT_KEY}" | base64 -d > /tmp/client-key.pem
    echo "► SSL Client Key Found.  Writing to /tmp/client-key.pem"
  fi

  if [[ -z "${PGBOUNCER_DATABASE_SSL_SERVER_CA}" ]]; then
    echo "► No SSL Server CA Found"
  else
    echo "${PGBOUNCER_DATABASE_SSL_SERVER_CA}" | base64 -d > /tmp/server-ca.pem
    echo "► SSL Server CA Found.  Writing to /tmp/server-ca.pem"
  fi

Anyway, I'll leave that with you 👍

In many cases, the %include directive would help. It would be nice to add it to entrypoint.sh
Yes, you can use your own pgbouncer.ini completely, but using a generator with parameters is more obvious.

Hello,

I've noticed after running this container for the first time the following error in the container logs:

ERROR could not open auth_file /etc/pgbouncer/userlist.txt: No such file or directory

I noticed in the documentation that the userlist.txt is supposed to be automatically created if it doesn't exist but that doesn't seem to be working.

Thanks!

It would be nice to be able to easily add multiple databases to a single pgbouncer configuration (for something like read-write splitting across master/slave instances).

Please correct me if I am wrong, but currently I believe this can only be done by supplying your own pgbouncer.ini

listen_port is fixed to 5432 (which is postgresql default) but pgbouncer unsually uses 6432. Could you please make this configurable through an environment variable?