Passbolt pro docker not accessible after few hours

Installation Issues
1

Checklist
I have read intro post: https://community.passbolt.com/t/about-the-installation-issues-category/12
I have read the tutorials, help and searched for similar issues
I provide relevant information about my server (component names and versions, etc.)
I provide a copy of my logs and healthcheck
I describe the steps I have taken to trouble shoot the problem
I describe the steps on how to reproduce the issue

Hi,

We are trying to install passbolt pro(passbolt:5.10.0-1-pro) docker installation, running behind HAProxy.
We have two app nodes with exact same setup including gpg and fingerprint were also same in both app nodes that running passbolt as docker containers.
These two app nodes are active-active and will be managed by HAProxy.
The end user passbolt url is working fine for few hours(around 4-6 hours) after sometime the service goes down and url shows 503 service not found.

When verified in HAProxy it logs as layer 7 passbolt_app down
then verified app nodes the container status is running, but the logs messages show like below.
When we do a simple docker restart of the container, the end user passbolt url starts working and everything works normally.
Inside container, I tried to manually remove the files from /var/lib/php/sessions still the same behaviour. After few hours the passbolt url stops working and i have to manually restart the already running container to bring the application back to usage.

Please find the app container logs below and suggest if any additional information is required, appreciate if anyone can help on this issue.

Cannot make/remove an entry for the specified session

Cannot make/remove an entry for the specified session

Cannot make/remove an entry for the specified session

Cannot make/remove an entry for the specified session

Cannot make/remove an entry for the specified session

Cannot make/remove an entry for the specified session

Cannot make/remove an entry for the specified session
2026-04-29 10:20:30,772 WARN received SIGTERM indicating exit request
2026-04-29 10:20:30,773 INFO waiting for php-fpm, nginx, cron to die
2026-04-29 10:20:30,773 WARN stopped: cron (terminated by SIGTERM)
2026-04-29 10:20:30,777 INFO stopped: nginx (exit status 0)
[29-Apr-2026 10:20:30] NOTICE: Terminating …
[29-Apr-2026 10:20:30] NOTICE: exiting, bye-bye!
2026-04-29 10:20:30,787 INFO stopped: php-fpm (exit status 0)

2

Hi Prasad,

I just replied to your sessions thread: https://community.passbolt.com/t/php-sessions-filling-up-disk/10336/3

You mentioned you already cleared /var/lib/php/sessions by hand and the issue came back after a few hours, which doesn’t fully fit a plain disk or inode exhaustion picture. The docker image itself is in wide use without this symptom, so the deployment-specific layer (HAProxy in front, plus the two-node setup) is the more likely place to look. Before guessing at exactly what, it would help to capture a bit more state.

A few asks:

  • Could you run the diagnostic from the other thread on both app nodes and paste both outputs? Comparing the healthy node against the failing one is more useful than either alone.
  • The diagnostic prints the live session.save_path. Worth confirming it actually points at /var/lib/php/sessions in your image, in case something else is overriding it.
  • Could you share your HAProxy backend block for passbolt, in particular option httpchk, the server lines, and any cookie or stick directives?

One thing worth flagging separately, not as a diagnosis. With two nodes active-active and PHP file based sessions sitting on each container’s local disk, the two nodes do not share session state. That may or may not be related to the 503 you are hitting, but it is worth knowing about. Sticky sessions on HAProxy or moving session storage to a shared backend (database or cache) would both address that.

Chat soon.

Cheers, Gareth

3

Hi Gareth,

Thanks for responding to my query.
Here are the details below.
Node1 Diagnostics

[node001 ~]$ sudo podman exec passbolt-CHOC sh -c '
>   echo -n "cron running:        "; pgrep -a cron || echo "no cron process"
>   echo -n "/etc/cron.d/php:     "; [ -f /etc/cron.d/php ] && echo "present" || echo "missing"
>   echo -n "/run/systemd/system: "; [ -d /run/systemd/system ] && echo "present (sessionclean cron skips when this exists)" || echo "absent"
>   echo -n "gc_maxlifetime:      "; php -r "echo ini_get(\"session.gc_maxlifetime\");"; echo
>   echo -n "save_path:           "; php -r "echo ini_get(\"session.save_path\") ?: \"/var/lib/php/sessions (default)\";"; echo
>   echo -n "session count:       "; ls /var/lib/php/sessions/ 2>/dev/null | wc -l
>   echo -n "newest session:      "; ls -lt /var/lib/php/sessions/ 2>/dev/null | sed -n "2p"
>   echo -n "oldest session:      "; ls -lt /var/lib/php/sessions/ 2>/dev/null | tail -1
>   echo -n "free inodes on /:    "; df -i / | tail -1
>   echo -n "free space on /:     "; df -h / | tail -1
> '
cron running:        183 cron -f -l
4419 CRON -f -l
4439 CRON -f -l
/etc/cron.d/php:     present
/run/systemd/system: absent
gc_maxlifetime:      1440
save_path:           /var/lib/php/sessions
session count:       0
newest session:      oldest session:      total 0
free inodes on /:    overlay        78118912 145398 77973514    1% /
free space on /:     overlay         149G   11G  139G   7% /

Node2 diagnostics

[node011 ~]$ sudo podman exec passbolt-SPOC sh -c '
>   echo -n "cron running:        "; pgrep -a cron || echo "no cron process"
>   echo -n "/etc/cron.d/php:     "; [ -f /etc/cron.d/php ] && echo "present" || echo "missing"
>   echo -n "/run/systemd/system: "; [ -d /run/systemd/system ] && echo "present (sessionclean cron skips when this exists)" || echo "absent"
>   echo -n "gc_maxlifetime:      "; php -r "echo ini_get(\"session.gc_maxlifetime\");"; echo
>   echo -n "save_path:           "; php -r "echo ini_get(\"session.save_path\") ?: \"/var/lib/php/sessions (default)\";"; echo
>   echo -n "session count:       "; ls /var/lib/php/sessions/ 2>/dev/null | wc -l
>   echo -n "newest session:      "; ls -lt /var/lib/php/sessions/ 2>/dev/null | sed -n "2p"
>   echo -n "oldest session:      "; ls -lt /var/lib/php/sessions/ 2>/dev/null | tail -1
>   echo -n "free inodes on /:    "; df -i / | tail -1
>   echo -n "free space on /:     "; df -h / | tail -1
> '
cron running:        1819 cron -f -l
/etc/cron.d/php:     present
/run/systemd/system: absent
gc_maxlifetime:      1440
save_path:           /var/lib/php/sessions
session count:       881
newest session:      -rw------- 1 www-data www-data 101 Apr 30 06:17 sess_30efcbb25911040a55e8c17d43fbb8b1
oldest session:      -rw------- 1 www-data www-data 101 Apr 30 03:50 sess_6313a99f8515a2270ff8707e3d76561b
free inodes on /:    overlay        78118912 143685 77975227    1% /
free space on /:     overlay         149G  9.6G  140G   7% /

HAProxy backend block for passbolt

backend passbolt_app
    mode http
    balance roundrobin
    cookie SERVERID insert indirect nocache

    option httpchk GET /healthcheck/status.json
    http-check expect status 200

    default-server inter 10s fall 3 rise 2
    no option log-health-checks

    server node001 10.112.XX.67:80 check cookie node001
    server node011 10.112.XX.67:80 check cookie node011

Additionally i have manually cleared the /var/lib/php/sessions from node1 and node2
to stay the passbolt app running
but now in node1 container logs i see a different error like below, even though db container is running fine.

10.112.160.68 - - [30/Apr/2026:04:36:26 +0000] "GET /healthcheck/status.json HTTP/1.0" 200 220 "-" "-"
2026-04-30 04:36:26,348 INFO reaped unknown pid 2295 (exit status 0)
10.112.160.68 - - [30/Apr/2026:04:36:36 +0000] "GET /healthcheck/status.json HTTP/1.0" 200 220 "-" "-"
2026-04-30 04:36:36,380 INFO reaped unknown pid 2301 (exit status 0)
10.112.160.68 - - [30/Apr/2026:04:36:46 +0000] "GET /healthcheck/status.json HTTP/1.0" 200 220 "-" "-"
2026-04-30 04:36:46,415 INFO reaped unknown pid 2307 (exit status 0)
10.112.160.68 - - [30/Apr/2026:04:36:56 +0000] "GET /healthcheck/status.json HTTP/1.0" 200 220 "-" "-"
2026-04-30 04:36:56,450 INFO reaped unknown pid 2313 (exit status 0)
2026-04-30 04:38:31 error: [Cake\Database\Exception\MissingConnectionException] Connection to Mysql could not be established: SQLSTATE[HY000] [2002] Connection timed out in /usr/share/php/passbolt/vendor/cakephp/cakephp/src/Database/Driver.php on line 203
Caused by: [PDOException] SQLSTATE[HY000] [2002] Connection timed out in /usr/share/php/passbolt/vendor/cakephp/cakephp/src/Database/Driver.php on line 192
2026-04-30 04:39:01 error: Could not connect to Database.
2026-04-30 04:39:31 error: [Cake\Database\Exception\MissingConnectionException] Connection to Mysql could not be established: SQLSTATE[HY000] [2002] Connection timed out in /usr/share/php/passbolt/vendor/cakephp/cakephp/src/Database/Driver.php on line 203
Caused by: [PDOException] SQLSTATE[HY000] [2002] Connection timed out in /usr/share/php/passbolt/vendor/cakephp/cakephp/src/Database/Driver.php on line 192
<!DOCTYPE html>
<html class="passbolt no-js no-passboltplugin version" lang="en">
<head>
    <meta charset="utf-8">
    <title>Passbolt | Error</title>
    <!--

Node1 DB container is running on a different server which is running as well

[dbnode001 ~]$ sudo podman ps
CONTAINER ID  IMAGE                             COMMAND               CREATED       STATUS       PORTS       NAMES
36e74e350c65  docker.io/library/mariadb:11.8.6  --wsrep-on=ON --w...  30 hours ago  Up 30 hours              passbolt-db-CHOC
4

G’day Prasad.

Thanks for the diagnostics.

Good news on the sessions side: both nodes have cron running, /etc/cron.d/php present, /run/systemd/system absent, and gc_maxlifetime at the default 1440. So sessionclean is firing as expected on both containers. The original “sessions filling the disk” theory isn’t what’s causing the outages.

The MySQL timeout in your node1 log is a separate issue, and there’s one thing in your HAProxy config worth flagging alongside it. option httpchk GET /healthcheck/status.json only checks that PHP responds. That endpoint is a small controller that returns a static “OK” string and never opens a database connection. So when node1’s PDO connection to MariaDB times out (your 04:38 log line), HAProxy still sees node1 as healthy and keeps sending it traffic. Users hit a node that can’t reach the database, while HAProxy’s stats say everything is up. That fits your “inaccessible after a few hours” pattern.

For the DB timeout itself, the cleanest first check is reachability from inside the app container, not just from the host:

sudo podman exec passbolt-CHOC sh -c 'time mariadb -h <db-host> -P 3306 -u <user> -p<pass> -e "SELECT 1"'

If that hangs, the fault is in the network path between app and DB nodes, not in passbolt. If it returns quickly, the timeout is happening elsewhere and we can dig further from there.

Independent of the DB issue, file-based sessions on two nodes with HAProxy in front are fragile by design: any restart or failover logs out every user pinned to the affected node. Two ways to fix that, both in my reply on the other thread:

DB-backed is the lower-friction option given you already have Galera in place.

Chat soon.

Cheers
Gareth

6

Hi Gareth,

G’day

Thanks for sharing your insights and recommendations.
Editing my previous post with latest updates.
I have followed the below approach for PHP sessions issue.

Now i see the sessions are stored inside database, considering the fact there are thousands of sessions building every day, at some stage database will also pile up with unwanted sessions history, do we need to delete the unwanted sessions by placing a trigger or manual or is it going to handle differently ?

Regarding MySQL timeout in node1, after adding the SESSION_DEFAULTS=database environment variable in docker-compose file, iam not seeing this message now in the either of my app container logs.

[Cake\Database\Exception\MissingConnectionException] Connection to Mysql could not be established: SQLSTATE[HY000] [2002] Connection timed out in /usr/share/php/passbolt/vendor/cakephp/cakephp/src/Database/Driver.php on line 203
Caused by: [PDOException] SQLSTATE[HY000] [2002] Connection timed out in /usr/share/php/passbolt/vendor/cakephp/cakephp/src/Database/Driver.php on line 192
2026-04-30 04:39:01 error: Could not connect to Database.

Even though iam able to access the passbolt url and application fine without any issue at the moment.
However Iam unable to connect to db container from app container using below commands

[csesupport@node001 ~]$ sudo podman exec passbolt-CHOC sh -c 'time mariadb -h 10.**.**.**.** -P 3306 -u root -pcsesuppXXX -e "SELECT 1"'
sh: 1: time: not found
[csesupport@pbsprdappla001 ~]$ sudo podman exec passbolt-CHOC sh -c 'mariadb -h 10.**.**.**.** -P 3306 -u root -pcsesuppXXX -e "SELECT 1"'
sh: 1: mariadb: not found
[csesupport@pbsprdappla001 ~]$ sudo podman exec passbolt-CHOC sh -c 'mysql -h 10.**.**.**.** -P 3306 -u root -pcsesuppXXX -e "SELECT 1"'
sh: 1: mysql: not found
[csesupport@pbsprdappla001 ~]$

My passbolt app is running on node1 host and mariadb is running as container in DB node host , i have used network_mode: host to connect between two containers.

7

After creating sessions table in DB container, placed a cron job to delete the unused sessions table records. Now issue seems resolved and passbolt app is accessible fine.
Thanks for your help and support @gyaresu

Regards,
Hari.