bitnami postgresql chart deployment crashloop

[daydone]

Name and Version

bitnami/postgresql-16.6.2

What architecture are you using?

amd64

What steps will reproduce the bug?

• In this environment: Kubernetes cluster with Longhorn storage class
• With this config: Deploy PostgreSQL using Bitnami Helm chart
• Run: helm install postgres -n dev -f ./postgresql-values.yaml oci://registry-1.docker.io/bitnamicharts/postgresql
• See error: PostgreSQL container crashes with "Bus error (core dumped)" during initialization

The error appears consistently during PostgreSQL database initialization with both 17.4.0 and 15.5.0 versions, and occurs specifically when PostgreSQL's initdb process tries to create configuration files.RetryClaude can make mistakes. Please double-check responses.

Are you using any custom parameters or values?

postgresql-values.yaml is

global:
  postgresql:
    auth:
      postgresPassword: "longhorn"
      username: "pg_admin"
      password: "supersecretpassword"
      database: "mydb"

nameOverride: "chirpstack-postgresql"
namespaceOverride: "dev"

image:
  tag: "15.5.0-debian-11-r0"

volumePermissions:
  enabled: true
  resources:
    requests:
      memory: "512Mi"
      cpu: "100m"
    limits:
      memory: "512Mi"
      cpu: "200m"

primary:
  extraEnvVars:
    - name: "BITNAMI_DEBUG"
      value: "true"
    - name: "POSTGRESQL_SHARED_PRELOAD_LIBRARIES"
      value: ""
    - name: "POSTGRESQL_SHARED_BUFFERS"
      value: "128MB"
  resources:
    requests:
      memory: "512Mi"
      cpu: "250m"
    limits:
      memory: "1Gi"
      cpu: "500m"
  securityContext:
    enabled: true
    fsGroup: 1001
    runAsUser: 1001
  containerSecurityContext:
    enabled: true
    runAsUser: 1001

What is the expected behavior?

I expect the statefulSet to deploy and be useable and accessible with the supersecretpassword and the ph_admin

What do you see instead?

Defaulted container "postgresql" out of: postgresql, init-chmod-data (init)
postgresql 19:51:51.25 INFO  ==> 
postgresql 19:51:51.34 INFO  ==> Welcome to the Bitnami postgresql container
postgresql 19:51:51.34 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
postgresql 19:51:51.35 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
postgresql 19:51:51.44 INFO  ==> 
postgresql 19:51:51.54 DEBUG ==> Configuring libnss_wrapper...
postgresql 19:51:51.84 INFO  ==> ** Starting PostgreSQL setup **
postgresql 19:51:52.15 INFO  ==> Validating settings in POSTGRESQL_* env vars..
postgresql 19:51:52.34 INFO  ==> Loading custom pre-init scripts...
postgresql 19:51:52.45 INFO  ==> Initializing PostgreSQL database...
postgresql 19:51:52.54 DEBUG ==> Ensuring expected directories/files exist...
postgresql 19:51:52.84 INFO  ==> pg_hba.conf file not detected. Generating it...
postgresql 19:51:52.85 INFO  ==> Generating local authentication configuration
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /bitnami/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 20
selecting default shared_buffers ... 400kB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
Bus error (core dumped)
child process exited with exit code 135
initdb: removing contents of data directory "/bitnami/postgresql/data"
running bootstrap script ... 

Additional information

I am not sure what I am doing wrong in my deployment to cause this repeated error.

creating configuration files ... ok
Bus error (core dumped)
child process exited with exit code 135

I have also tried a MUCH more simplified version of my values file with no change in behavior.

[daydone]

Hi is there any way to get some help on this?

[daydone]

Im pretty sure it has to do with the nature of the replication of the longhorn pv and the postgres replication being redundant and causing issues so I tried local-path-provisioner bound to a specific worker node and I still get the same crashlooping. I have validated that the deployment does create the files but then crashes and deletes them.

~]# ls -ltr /opt/local-path-provisioner/postgres-data/data/
total 76
drwx------. 4 user1 user1 4096 Apr 11 17:18 pg_wal
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_twophase
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_subtrans
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_snapshots
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_serial
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_notify
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_dynshmem
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_commit_ts
drwx------. 2 user1 user1 4096 Apr 11 17:18 global
-rw-------. 1 user1 user1 0 Apr 11 17:18 postgresql.conf
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_xact
-rw-------. 1 user1 user1 3 Apr 11 17:18 PG_VERSION
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_tblspc
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_stat_tmp
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_stat
drwx------. 2 user1 user1 4096 Apr 11 17:18 pg_replslot
drwx------. 4 user1 user1 4096 Apr 11 17:18 pg_multixact
drwx------. 4 user1 user1 4096 Apr 11 17:18 pg_logical
drwx------. 3 user1 user1 4096 Apr 11 17:18 base
-rw-------. 1 user1 user1 67 Apr 11 17:18 postmaster.pid

[daydone]

I also watched resources and see nothing indicative of OOM or any resource constriction. I was wondering if it might be a data ownership issue in the pv as with the local-path the ownership is my local server user, "user1" for this anonymized data, and thought it probably is meant to be the postgres user?

[daydone]

When I boot a test pod and try to run postgresql I see the following:

I have no name!@pg-debugger:/bitnami/postgresql$ /opt/bitnami/scripts/postgresql/run.sh
postgresql 17:54:58.92 INFO  ==> ** Starting PostgreSQL **
'2025-04-11 17:54:58.952 GMT [16] LOG:  skipping missing configuration file "/bitnami/postgresql/data/postgresql.auto.conf"
2025-04-11 17:54:58.952 GMT [16] FATAL:  "/bitnami/postgresql/data" is not a valid data directory
2025-04-11 17:54:58.952 GMT [16] DETAIL:  File "/bitnami/postgresql/data/PG_VERSION" is missing.

[daydone]

Aliased as postgresql and ran the initdb, I get the following

I have no name!@pg-debugger:/$ whoami
postgres
I have no name!@pg-debugger:/$ /opt/bitnami/postgresql/bin/initdb -D /bitnami/postgresql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /bitnami/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 25
selecting default "shared_buffers" ... 400kB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... Bus error (core dumped)
child process exited with exit code 135
initdb: removing contents of data directory "/bitnami/postgresql/data"

[daydone]

Even with

    "volumes": [{
      "name": "pgdata",
      "emptyDir": {}

I still get the same bus error. I think this is linked in some way to mmap, I am not familiar enough with the build process to perform further debug on this...

[carrodher]

Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.

For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:

• Why non-root containers are important for security
• Use Non-Root Containers
• Work With Non-Root Containers for Bitnami Applications
• Running non-root containers on Openshift

These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.