Wallabag mariadb: Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: '172.29.0.33' (This connection closed normally without authentication)

[jeff47]

I am seeing the following error/warning in my the logs of the wallabag-db docker container. I saw this error coming up and decided to reinstall everything, since I had only a few things saved. I removed the whole wallabag volume and reinstalled, but the warning is still there.

Any clues on how to troubleshoot?

wallabag-db  | 2023-09-14 18:38:20 0 [Note] Starting MariaDB 11.1.2-MariaDB-1:11.1.2+maria~ubu2204 source revision 9bc25d98209df6810f7a7d5e7dd3ae677a313ab5 as process 1
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Number of transaction pools: 1
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
wallabag-db  | 2023-09-14 18:38:20 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Using liburing
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Completed initialization of buffer pool
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: End of log at LSN=47375
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Opened 3 undo tablespaces
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: log sequence number 47375; transaction id 14
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
wallabag-db  | 2023-09-14 18:38:20 0 [Note] Plugin 'FEEDBACK' is disabled.
wallabag-db  | 2023-09-14 18:38:20 0 [Note] Plugin 'wsrep-provider' is disabled.
wallabag-db  | 2023-09-14 18:38:20 0 [Note] InnoDB: Buffer pool(s) load completed at 230914 18:38:20
wallabag-db  | 2023-09-14 18:38:20 0 [Note] Server socket created on IP: '0.0.0.0'.
wallabag-db  | 2023-09-14 18:38:20 0 [Note] Server socket created on IP: '::'.
wallabag-db  | 2023-09-14 18:38:20 0 [Note] mariadbd: Event Scheduler: Loaded 0 events
wallabag-db  | 2023-09-14 18:38:20 0 [Note] mariadbd: ready for connections.
wallabag-db  | Version: '11.1.2-MariaDB-1:11.1.2+maria~ubu2204'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
wallabag-db  | 2023-09-14 18:38:20 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: '172.29.0.33' (This connection closed normally without authentication)

[benjamin051000]

I see the same thing, and the container is listed as unhealthy.

[jeff47]

I see the same thing, and the container is listed as unhealthy.

I think this might be related to https://github.com/wallabag/docker/issues/381. When I fixed the healthcheck, the connection error went away.

Try changing your docker-compose.yml to look like this:

  wallabag-db:
    image: mariadb
    container_name: wallabag-db
    restart: unless-stopped
    env_file: docker.env
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
    volumes:
      - ./wallabag/data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "/usr/local/bin/healthcheck.sh" ,"--innodb_initialized"]
      start_period: 5s
      interval: 20s
      timeout: 3s
      retries: 5

[Aarkon]

Doesn't work for me, I get [Warning] Access denied for user 'root'@'localhost' (using password: NO). 🤔
When I instead use test: [ "CMD", "healthcheck.sh", "--su-mysql", "--connect" ], my container is no longer unhealthy, but in its logs I still see [Warning] Access denied for user 'mysql'@'127.0.0.1' (using password: NO) which is basically the same as before where the connecting user was root.

Also, the main wallabag container apparently can't connect to the database anymore, even though I'm able to open a shell in there and run mysql -h db ${SYMFONY__ENV__DATABASE_NAME} -u${SYMFONY__ENV__DATABASE_USER} -p${SYMFONY__ENV__DATABASE_PASSWORD}. When trying to log in through the web interface though, I only see Authentication request could not be processed due to a system problem. which would be somewhat of a coincidence if it was totally unrelated to the issue described before (even though I have not enabled more extensive logging to verify that). Any ideas?

[cboergermann]

Doesn't work for me, I get [Warning] Access denied for user 'root'@'localhost' (using password: NO). 🤔 When I instead use test: [ "CMD", "healthcheck.sh", "--su-mysql", "--connect" ], my container is no longer unhealthy, but in its logs I still see [Warning] Access denied for user 'mysql'@'127.0.0.1' (using password: NO) which is basically the same as before where the connecting user was root.

Also, the main wallabag container apparently can't connect to the database anymore, even though I'm able to open a shell in there and run mysql -h db ${SYMFONY__ENV__DATABASE_NAME} -u${SYMFONY__ENV__DATABASE_USER} -p${SYMFONY__ENV__DATABASE_PASSWORD}. When trying to log in through the web interface though, I only see Authentication request could not be processed due to a system problem. which would be somewhat of a coincidence if it was totally unrelated to the issue described before (even though I have not enabled more extensive logging to verify that). Any ideas?

Same here :(

[AloisCRR]

I had the same problem and managed to solve it by using docker volumes instead of bind mounts. Here's my docker-compose. Remember to set the SYMFONY__ENV__DOMAIN_NAME env variable to the host of your server, in my case I'm hosting it in my RPi so it's in lan.

version: '3'
services:
  wallabag:
    image: wallabag/wallabag
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
      - SYMFONY__ENV__DATABASE_HOST=db
      - SYMFONY__ENV__DATABASE_PORT=3306
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=wallabag
      - SYMFONY__ENV__DATABASE_PASSWORD=wallapass
      - SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
      - SYMFONY__ENV__DATABASE_TABLE_PREFIX="wallabag_"
      - SYMFONY__ENV__MAILER_DSN=smtp://127.0.0.1
      - SYMFONY__ENV__FROM_EMAIL=wallabag@example.com
      - SYMFONY__ENV__DOMAIN_NAME=http://192.168.1.10:8082
      - SYMFONY__ENV__SERVER_NAME="Your wallabag instance"
    ports:
      - 8082:80
    volumes:
      - wallabag-images:/var/www/wallabag/web/assets/images
    healthcheck:
      test: ["CMD", "wget" ,"--no-verbose", "--tries=1", "--spider", "http://localhost"]
      interval: 1m
      timeout: 3s
    depends_on:
      - db
      - redis
  db:
    image: mariadb
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
    volumes:
      - wallabag-data:/var/lib/mysql
    healthcheck:
      test: ['CMD', '/usr/local/bin/healthcheck.sh', '--innodb_initialized']

      interval: 20s
      timeout: 3s
  redis:
    image: redis:alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 20s
      timeout: 3s

volumes:
  wallabag-images:
  wallabag-data:

[cboergermann]

I finally found a solution... at least for me

The Readme of https://github.com/wallabag/docker says that

If there is a version upgrade that needs a database migration. [...]

do this

$ docker exec -t NAME_OR_ID_OF_YOUR_WALLABAG_CONTAINER /var/www/wallabag/bin/console doctrine:migrations:migrate --env=prod --no-interaction

After I did that, everything worked fine again!

[Aarkon]

@cboergermann That works for me as well! 🎉

Funny that I didn't notice that particular section earlier. Git says the last change to the README file was five months ago, but I'm pretty positive that this fix wasn't there the last time I looked. 🙈 Or maybe it was merged just recently, I'm too lazy to look it up right now.

[sukatraps]

Same problem (as described in the original issue) for me.

[Warning] Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: '172.27.0.4' (This connection closed normally without authentication)

Thanks to @jeff47 for the hint on #381. This solved at least the additional health status issue I had.

[mariobraun]

there is a problem with the latest mariadb image - go back to version 11.1 (GA) db:

   image: mariadb:11.1

...and all works for me

Did also the healthcheck fix in the mariadb part:

      healthcheck:
            test: ['CMD', '/usr/local/bin/healthcheck.sh', '--innodb_initialized']
            start_period: 5s
            timeout: 5s
            interval: 5s
            retries: 5

[jtagcat]

@jeff47 this issue can be closed.

@mariobraun This is unrelated to this issue. If you were using mariadb:11 (or :latest), you updated to 11.3, which is broken

Downgrading to 11.2 is the current workaround, or it should just fix itself tomorrow by pulling latest again. EDIT: It is fixed. Just pull the mariadb image again. docker compose up -d --pull

[grooverdan]

recommend having 'healthcheck.sh', '--connect', '--innodb_initialized'. I think there's a chance the second could become true before the first. Something I should fix upstream. I suspect the full path of healthcheck.sh is unneeded.

Images updates have happened, repull should be sufficient. Appoligies.

Integrating the health check into service dependency:

    depends_on:
      db:
         condition: service_healthy

[jtagcat]

Container orchestration doesn't like the conditions. Kubernetes does not support this at all, docker compose often leads to failures by (most frequently) timeout. When you reboot, the service likely won't come up.

Creating dependency chains is a bad idea, instead the application should wait/manage its connection dependencies itself. Even if depends_on..condition is used, it only applies on first start.

Currently, wallabag container restarts if it doesn't have a database, which works, and is imo preferable to your proposal. Instead, a better change would be to change wallabag container itself to wait while db is unavailable. If you want to track the change, create a new issue, as it is unrelated to this.

More reading (attention on to why there are multiple probes): https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

If you, however feel, that your proposal should be considered by others as well, actually make a PR.

[sukatraps]

Unfortunately I still find the warning message described in the first entry:

2024/02/22 16:47:07,stderr,2024-02-22 15:47:07 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: '192.168.32.4' (This connection closed normally without authentication)
2024/02/22 16:47:06,stderr,2024-02-22 15:47:06 0 [Note] InnoDB: Buffer pool(s) load completed at 240222 15:47:06
2024/02/22 16:47:06,stderr,Version: '11.3.2-MariaDB-1:11.3.2+maria~ubu2204'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution