using Postgres, app tries to connect as root user #28

New Issue

2026-05-14T10:08:31Z

amras commented

2026-05-14 10:08:31 +00:00

Observed

abra app new hedgedoc 3.0.10+1.10.8
abra app config my.hedgedoc.domainand uncomment the two postgres lines
abra app secret generate my.hedgedoc.domain --all
abra app deploy my.hedgedoc.domain
docker service logs my_hedgedoc_domain_db:

...
my_hedgedoc_domain_db.1.hash@hostname    | 2026-05-14 09:49:15.096 UTC [7] LOG:  database system is ready to accept connections
my_hedgedoc_domain_db.1.hash@hostname    | 2026-05-14 09:49:18.383 UTC [105] FATAL:  role "root" does not exist
my_hedgedoc_domain_db.1.hash@hostname    | 2026-05-14 09:49:48.507 UTC [105] FATAL:  role "root" does not exist
my_hedgedoc_domain_db.1.hash@hostname    | 2026-05-14 09:50:18.637 UTC [105] FATAL:  role "root" does not exist

Analysis

The only issue I could find in the compose is that CMD_DB_USERNAME is incorrectly specified as CMD_DB_USER (see docs). But that shouldn't matter, because the entrypoint sets CMD_DB_URL which should override CMD_DB_USERNAME. And in any case, changing to CMD_DB_USERNAME didn't seem to fix things.

## Observed 1. `abra app new hedgedoc 3.0.10+1.10.8` 2. `abra app config my.hedgedoc.domain`and uncomment the two postgres lines 3. `abra app secret generate my.hedgedoc.domain --all` 4. `abra app deploy my.hedgedoc.domain` 5. `docker service logs my_hedgedoc_domain_db`: ``` ... my_hedgedoc_domain_db.1.hash@hostname | 2026-05-14 09:49:15.096 UTC [7] LOG: database system is ready to accept connections my_hedgedoc_domain_db.1.hash@hostname | 2026-05-14 09:49:18.383 UTC [105] FATAL: role "root" does not exist my_hedgedoc_domain_db.1.hash@hostname | 2026-05-14 09:49:48.507 UTC [105] FATAL: role "root" does not exist my_hedgedoc_domain_db.1.hash@hostname | 2026-05-14 09:50:18.637 UTC [105] FATAL: role "root" does not exist ``` ## Analysis The only issue I could find in the compose is that `CMD_DB_USERNAME` is incorrectly specified as `CMD_DB_USER` (see [docs](https://docs.hedgedoc.org/configuration/#hedgedoc-basics)). But that shouldn't matter, because the entrypoint sets `CMD_DB_URL` which should override `CMD_DB_USERNAME`. And in any case, changing to `CMD_DB_USERNAME` didn't seem to fix things.

amras commented

2026-05-14 10:45:07 +00:00

A bit more context:

I initially thought this log was a breaking issue, because I was having difficulty getting my services to communicate in a multi-node setup.

But, I now have a working setup on a single node server, and the "FATAL" logs are still present. So it might be lower prio, and possibly upstream.

(I guess I'll have to investigate separately why I can't have app on a worker node, and figure out if this is related.)

A bit more context: I initially thought this log was a breaking issue, because I was having difficulty getting my services to communicate in a multi-node setup. But, I now have a working setup on a single node server, and the "FATAL" logs are still present. So it might be lower prio, and possibly upstream. (I guess I'll have to investigate separately why I can't have `app` on a worker node, and figure out if this is related.)

fauno commented

2026-05-14 12:37:26 +00:00

hey @amras could you check the processes on the postgresql container? if hedgedoc is working, the rejected connections from root may come from another client, possibly health checks?

also i'm not sure what you mean by multinode setup, are you connecting hedgedoc to a remote postgresql? from the same recipe?

hey @amras could you check the processes on the postgresql container? if hedgedoc is working, the rejected connections from root may come from another client, possibly health checks? also i'm not sure what you mean by multinode setup, are you connecting hedgedoc to a remote postgresql? from the same recipe?

amras commented

2026-05-14 20:18:51 +00:00

I think pg health checks are a likely hypothesis. I'll try and look at the processes when I have a moment.

By multi-node setup, I mean that I have two machines in my docker swarm. The manager is running the db service defined in compose.postgresql.yml, and a worker is running the app service. For some reason, app sometimes reports that it can't connect to the database and locks on deployment. Which is unusual, because having a database on another node hasn't been an issue in other recipes.

I think pg health checks are a likely hypothesis. I'll try and look at the processes when I have a moment. By multi-node setup, I mean that I have two machines in my docker swarm. The manager is running the `db` service defined in `compose.postgresql.yml`, and a worker is running the `app` service. For some reason, `app` sometimes reports that it can't connect to the database and locks on deployment. Which is unusual, because having a database on another node hasn't been an issue in other recipes.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/hedgedoc#28