repeated loss of all data (maybe related to container updates) #101

New Issue

OVERLORD · 2026-02-04T17:11:57+03:00

OVERLORD commented

2026-02-04 17:11:57 +03:00

Originally created by @benj919 on GitHub (May 16, 2021).

Hi all

I've been running planka from the sample docker-compose file (plus host mounted volumes) for a few months and I've semi-regularly experienced a complete data loss with it; meaning I lost all boards and usernames.

Admittedly if this were a widespread problem it would be a bit more visible than just me writing this now. I suspect this might be a combination of how docker-compose, docker networks, and possibly restarting/rebuilding containers using ouroboros are interacting.

The log from the planka container show this error message:

error: Sending 500 ("Server Error") response: 
 AdapterError: Unexpected error from database adapter: relation "public.user_account" does not exist
    at fn (/app/api/helpers/get-user.js:21:29)
    at wrapper (/app/node_modules/@sailshq/lodash/lib/index.js:3282:19)
    at Deferred.parley.retry [as _handleExec] (/app/node_modules/machine/lib/private/help-build-machine.js:1016:29)
    at Deferred.exec (/app/node_modules/parley/lib/private/Deferred.js:286:10)
    at Deferred.tryCatcher (/app/node_modules/bluebird/js/release/util.js:11:23)
    at ret (eval at makeNodePromisifiedEval (/app/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:14:23)
    at Deferred.toPromise (/app/node_modules/parley/lib/private/Deferred.js:572:19)
    at Deferred.then (/app/node_modules/parley/lib/private/Deferred.js:431:22)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:94:5)
error: Sending 500 ("Server Error") response: 
 AdapterError: Unexpected error from database adapter: relation "public.user_account" does not exist
    at fn (/app/api/helpers/get-user.js:21:29)
    at wrapper (/app/node_modules/@sailshq/lodash/lib/index.js:3282:19)
    at Deferred.parley.retry [as _handleExec] (/app/node_modules/machine/lib/private/help-build-machine.js:1016:29)
    at Deferred.exec (/app/node_modules/parley/lib/private/Deferred.js:286:10)
    at Deferred.tryCatcher (/app/node_modules/bluebird/js/release/util.js:11:23)
    at ret (eval at makeNodePromisifiedEval (/app/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:14:23)
    at Deferred.toPromise (/app/node_modules/parley/lib/private/Deferred.js:572:19)
    at Deferred.then (/app/node_modules/parley/lib/private/Deferred.js:431:22)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:94:5)

The log from the postgresql container looks like this:

Success. You can now start the database server using:

    pg_ctl -D ' /var/lib/postgresql/data' -l logfile start

waiting for server to start....2021-05-15 22:53:03.930 UTC [49] LOG:  starting PostgreSQL 13.3 (Debian 13.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2021-05-15 22:53:03.931 UTC [49] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-05-15 22:53:03.936 UTC [50] LOG:  database system was shut down at 2021-05-15 22:53:03 UTC
2021-05-15 22:53:03.943 UTC [49] LOG:  database system is ready to accept connections
 done
server started
CREATE DATABASE


/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*

2021-05-15 22:53:04.444 UTC [49] LOG:  received fast shutdown request
waiting for server to shut down....2021-05-15 22:53:04.445 UTC [49] LOG:  aborting any active transactions
2021-05-15 22:53:04.447 UTC [49] LOG:  background worker "logical replication launcher" (PID 56) exited with exit code 1
2021-05-15 22:53:04.450 UTC [51] LOG:  shutting down
2021-05-15 22:53:04.461 UTC [49] LOG:  database system is shut down
 done
server stopped

PostgreSQL init process complete; ready for start up.

2021-05-15 22:53:04.582 UTC [1] LOG:  starting PostgreSQL 13.3 (Debian 13.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2021-05-15 22:53:04.582 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2021-05-15 22:53:04.583 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2021-05-15 22:53:04.584 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-05-15 22:53:04.588 UTC [77] LOG:  database system was shut down at 2021-05-15 22:53:04 UTC
2021-05-15 22:53:04.593 UTC [1] LOG:  database system is ready to accept connections

and docker ps show the postgres container being updated more recently than the planka app container itself:

postgres:latest             "docker-entrypoint.s…"   20 hours ago   Up 20 hours           5432 tcp                planka_postgres_1
meltyshev/planka:latest     "docker-entrypoint.s…"   36 hours ago   Up 36 hours           0.0.0.0:3000->1337/tcp  planka_planka_1

All containers are run on a truenas scale server with docker-compose (planka and ouroboros). I'm not exactly sure how ourobors works, but it's possible it takes individual containers down and rebuilds them independently of what is connected to them, e.g taking the db server down without touching the planka container itself. Disabling or changing the settings of ouroboros is certainly possible though I'm not sure it is actually the cause of problem. It might also be that planka is not able to reconnect to the db after such an update?

Thanks for the great app and any potential help here.

Originally created by @benj919 on GitHub (May 16, 2021). Hi all I've been running planka from the sample docker-compose file (plus host mounted volumes) for a few months and I've semi-regularly experienced a complete data loss with it; meaning I lost all boards and usernames. Admittedly if this were a widespread problem it would be a bit more visible than just me writing this now. I suspect this might be a combination of how docker-compose, docker networks, and possibly restarting/rebuilding containers using [ouroboros](https://github.com/pyouroboros/ouroboros) are interacting. The log from the planka container show this error message: ``` error: Sending 500 ("Server Error") response: AdapterError: Unexpected error from database adapter: relation "public.user_account" does not exist at fn (/app/api/helpers/get-user.js:21:29) at wrapper (/app/node_modules/@sailshq/lodash/lib/index.js:3282:19) at Deferred.parley.retry [as _handleExec] (/app/node_modules/machine/lib/private/help-build-machine.js:1016:29) at Deferred.exec (/app/node_modules/parley/lib/private/Deferred.js:286:10) at Deferred.tryCatcher (/app/node_modules/bluebird/js/release/util.js:11:23) at ret (eval at makeNodePromisifiedEval (/app/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:14:23) at Deferred.toPromise (/app/node_modules/parley/lib/private/Deferred.js:572:19) at Deferred.then (/app/node_modules/parley/lib/private/Deferred.js:431:22) at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:94:5) error: Sending 500 ("Server Error") response: AdapterError: Unexpected error from database adapter: relation "public.user_account" does not exist at fn (/app/api/helpers/get-user.js:21:29) at wrapper (/app/node_modules/@sailshq/lodash/lib/index.js:3282:19) at Deferred.parley.retry [as _handleExec] (/app/node_modules/machine/lib/private/help-build-machine.js:1016:29) at Deferred.exec (/app/node_modules/parley/lib/private/Deferred.js:286:10) at Deferred.tryCatcher (/app/node_modules/bluebird/js/release/util.js:11:23) at ret (eval at makeNodePromisifiedEval (/app/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:14:23) at Deferred.toPromise (/app/node_modules/parley/lib/private/Deferred.js:572:19) at Deferred.then (/app/node_modules/parley/lib/private/Deferred.js:431:22) at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:94:5) ``` The log from the postgresql container looks like this: ``` Success. You can now start the database server using: pg_ctl -D ' /var/lib/postgresql/data' -l logfile start waiting for server to start....2021-05-15 22:53:03.930 UTC [49] LOG: starting PostgreSQL 13.3 (Debian 13.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit 2021-05-15 22:53:03.931 UTC [49] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2021-05-15 22:53:03.936 UTC [50] LOG: database system was shut down at 2021-05-15 22:53:03 UTC 2021-05-15 22:53:03.943 UTC [49] LOG: database system is ready to accept connections done server started CREATE DATABASE /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/* 2021-05-15 22:53:04.444 UTC [49] LOG: received fast shutdown request waiting for server to shut down....2021-05-15 22:53:04.445 UTC [49] LOG: aborting any active transactions 2021-05-15 22:53:04.447 UTC [49] LOG: background worker "logical replication launcher" (PID 56) exited with exit code 1 2021-05-15 22:53:04.450 UTC [51] LOG: shutting down 2021-05-15 22:53:04.461 UTC [49] LOG: database system is shut down done server stopped PostgreSQL init process complete; ready for start up. 2021-05-15 22:53:04.582 UTC [1] LOG: starting PostgreSQL 13.3 (Debian 13.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit 2021-05-15 22:53:04.582 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2021-05-15 22:53:04.583 UTC [1] LOG: listening on IPv6 address "::", port 5432 2021-05-15 22:53:04.584 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2021-05-15 22:53:04.588 UTC [77] LOG: database system was shut down at 2021-05-15 22:53:04 UTC 2021-05-15 22:53:04.593 UTC [1] LOG: database system is ready to accept connections ``` and docker ps show the postgres container being updated more recently than the planka app container itself: ``` postgres:latest "docker-entrypoint.s…" 20 hours ago Up 20 hours 5432 tcp planka_postgres_1 meltyshev/planka:latest "docker-entrypoint.s…" 36 hours ago Up 36 hours 0.0.0.0:3000->1337/tcp planka_planka_1 ``` All containers are run on a truenas scale server with docker-compose (planka and ouroboros). I'm not exactly sure how ourobors works, but it's possible it takes individual containers down and rebuilds them independently of what is connected to them, e.g taking the db server down without touching the planka container itself. Disabling or changing the settings of ouroboros is certainly possible though I'm not sure it is actually the cause of problem. It might also be that planka is not able to reconnect to the db after such an update? Thanks for the great app and any potential help here.

OVERLORD commented

2026-02-04 17:12:00 +03:00

@nickbe commented on GitHub (May 24, 2021):

My recommendation (and yes I don't like docker at all) - PLANKA is based on node and PostgreSQL - so some simple kindergarden requirements which you should be able to provide without even thinking of docker.

But if you must - use only the standard docker tools and refrain from using other non-supported third party docker addons or other hacks. PLANKA is not production ready in an enterprise environment - not yet - but it will be. After that and when other important features are working there will surely be a point when there's gonna be time to handle docker related issues. But I think for now it's a waste of time - for reasons above.

@nickbe commented on GitHub (May 24, 2021): My recommendation (and yes I don't like docker at all) - PLANKA is based on node and PostgreSQL - so some simple kindergarden requirements which you should be able to provide without even thinking of docker. But if you must - use only the standard docker tools and refrain from using other non-supported third party docker addons or other hacks. PLANKA is not production ready in an enterprise environment - not yet - but it will be. After that and when other important features are working there will surely be a point when there's gonna be time to handle docker related issues. But I think for now it's a waste of time - for reasons above.

OVERLORD commented

2026-02-04 17:12:06 +03:00

@benj919 commented on GitHub (May 25, 2021):

I'm not quite sure what you want to tell me here... Planka is currently provided as a docker image so that's what I'm using. Ouroboros is a simple script in a stand-alone container issuing docker stop, pull, and start/run commands, nothing about it being an unsupported hack or addon. Such auto-updates might not be the best idea but that is another topic.

Planka is clearly labelled as alpha, it's not like I put days worth of boards into it to just lose them. I have put some small sample project and boards into it with ~4 lists and maybe ten issues.

The issue might be because the db container gets rebuild or not, or it might be related to how planka is (un)able to handle losing the db connection, or something completely else. I put this here for the author(s) to take a look and decide if it's worth their time to investigate. That's what an alpha is for after all.

@benj919 commented on GitHub (May 25, 2021): I'm not quite sure what you want to tell me here... Planka is currently provided as a docker image so that's what I'm using. Ouroboros is a simple script in a stand-alone container issuing docker stop, pull, and start/run commands, nothing about it being an unsupported hack or addon. Such auto-updates might not be the best idea but that is another topic. Planka is clearly labelled as alpha, it's not like I put days worth of boards into it to just lose them. I have put some small sample project and boards into it with ~4 lists and maybe ten issues. The issue might be because the db container gets rebuild or not, or it might be related to how planka is (un)able to handle losing the db connection, or something completely else. I put this here for the author(s) to take a look and decide if it's worth their time to investigate. That's what an alpha is for after all.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#101