Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jeff47 opened this issue Sep 15, 2023 · 13 comments

Comments

@jeff47
Copy link

jeff47 commented Sep 15, 2023

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
Copy link

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

@jeff47
Copy link
Author

jeff47 commented Sep 17, 2023

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

I think this might be related to #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
Copy link

Aarkon commented Dec 11, 2023

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
Copy link

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
Copy link

AloisCRR commented Jan 4, 2024

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
Copy link

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
Copy link

Aarkon commented Jan 19, 2024

@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
Copy link

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
Copy link

mariobraun commented Feb 21, 2024

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
Copy link

jtagcat commented Feb 22, 2024

@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
Copy link

grooverdan commented Feb 22, 2024

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
Copy link

jtagcat commented Feb 22, 2024

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
Copy link

sukatraps commented Feb 22, 2024

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

@jeff47 jeff47 closed this as completed Feb 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants