MySQL issues on some devices.

[mariushosting]

Steps to reproduce the problem

The Mixpost docker container just can't connect to the database.

Expected behaviour

Should connect to the MySQL database without issue

Actual behaviour

Impossible to connect to the MySQL database

Detailed description

I'm a tech guy that makes hundreds of Synology guides and recently made a guide for Mixpost. https://mariushosting.com/how-to-install-mixpost-on-your-synology-nas/ This container works on my NAS, but not on all Synology models.

The issue is related to the mysql database. https://www.reddit.com/r/synologynas/comments/1b1tzoz/issue_with_mixpost/ I have installed phpmyadmin to better investigate the issue and I can see the user is created without issue, but the connection is dropped and users get an internal error issue when they try to access Mixpost on frontend.

Can you please investigate more or offer a Postgres solution instead of MySQL ? Thank you!

Specifications

MixPost Docker Version 1.4.0

[nubbyninja]

bump.

[rayqusa]

monitoring

[uhlhosting]

Ok, such devices were never mentioned as supported in first place. So I do not see how this is a bug rather than a suggestion, and should be or it is already tracked in a roadmap.

P.S. You being a tech guys is nice, most of us here are, so that does not make all apps ready for NAS!

[mariushosting]

Ok, such devices were never mentioned as supported in first place. So I do not see how this is a bug rather than a suggestion, and should be or it is already tracked in a roadmap.

P.S. You being a tech guys is nice, most of us here are, so that does not make all apps ready for NAS!

The NAS use Docker and we have a compose for this. I can't replicate the issue on my NAS using Mixpost but there is some issue related to the mysql connection. The suggestion in this case is to have a Postgres solution instead of MySQL. I also want to use the PRO version.

Thank you for your hard work!

[DominArsen]

Hello, I'm continuing to set up Mixpost on a DS1821+ following your excellent @mariushosting tutorial. However, I'm encountering a problem when trying to connect to the administrator interface. After entering the credentials "admin@example.com" and "changeme" on the login page, I'm unable to connect, and the logs don't seem to indicate any immediate problem.

Here are the logs I was able to collect:

For the "_Mixpost-DB_logs" container:

[Entrypoint] MySQL Docker Image 8.0.32-1.2.11-server [Entrypoint] Starting MySQL 8.0.32-1.2.11-server 2024-03-03T14:02:12.509712Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead. 2024-03-03T14:02:12.511193Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.32) starting as process 1 2024-03-03T14:02:12.517013Z 0 [Warning] [MY-000054] [Server] World-writable config file '/var/lib/mysql/auto.cnf' is ignored. 2024-03-03T14:02:12.517137Z 0 [Warning] [MY-010107] [Server] World-writable config file '/var/lib/mysql/auto.cnf' has been removed. 2024-03-03T14:02:12.517393Z 0 [Warning] [MY-010075] [Server] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: XXXXXXXXXXXXXXXXXXX. 2024-03-03T14:02:12.798209Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2024-03-03T14:03:41.214385Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2024-03-03T14:03:50.284553Z 0 [Warning] [MY-010068] [Server] CA certificate XX.pem is self signed. 2024-03-03T14:03:50.284610Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel. 2024-03-03T14:03:50.470641Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: XXXX, socket: /var/run/mysqld/mysqlx.sock 2024-03-03T14:03:50.470688Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.32' socket: '/var/lib/mysql/mysql.sock' port: XXXX MySQL Community Server - GPL.

For the "_Mixpost_logs" container: INFO Configuration cached successfully. INFO Application cache cleared successfully. INFO Routes cached successfully. Starting periodic command scheduler cron ...done. Mixpost has started! 2024-03-03 14:02:19,856 INFO Set uid to user 0 succeeded 2024-03-03 14:02:19,881 INFO supervisord started with pid 22 2024-03-03 14:02:20,883 INFO spawned: 'mixpost_horizon_00' with pid 24 2024-03-03 14:02:20,887 INFO spawned: 'nginx' with pid 25 2024-03-03 14:02:20,889 INFO spawned: 'php-fpm' with pid 26 2024-03-03 14:02:22,375 INFO success: mixpost_horizon_00 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2024-03-03 14:02:22,375 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2024-03-03 14:02:22,375 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

For the "_Mixpost-REDIS_logs" container: 1:C 03 Mar 2024 13:49:34.795 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 1:C 03 Mar 2024 13:49:34.795 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1:C 03 Mar 2024 13:49:34.795 * Redis version=7.2.4, bits=64, commit=00000000, modified=0, pid=1, just started 1:C 03 Mar 2024 13:49:34.795 * Configuration loaded 1:M 03 Mar 2024 13:49:34.796 * monotonic clock: POSIX clock_gettime 1:M 03 Mar 2024 13:49:34.797 * Running mode=standalone, port=XXXX. 1:M 03 Mar 2024 13:49:34.797 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 1:M 03 Mar 2024 13:49:34.797 * Server initialized 1:M 03 Mar 2024 13:49:34.797 * Reading RDB base file on AOF loading... 1:M 03 Mar 2024 13:49:34.797 * Loading RDB produced by version 7.2.4 1:M 03 Mar 2024 13:49:34.797 * RDB age 302 seconds 1:M 03 Mar 2024 13:49:34.797 * RDB memory usage when created 0.83 Mb 1:M 03 Mar 2024 13:49:34.797 * RDB is base AOF 1:M 03 Mar 2024 13:49:34.797 * Done loading RDB, keys loaded: 0, keys expired: 0. 1:M 03 Mar 2024 13:49:34.797 * DB loaded from base file appendonly.aof.1.base.rdb: 0.000 seconds 1:M 03 Mar 2024 13:49:34.797 * DB loaded from append only file: 0.000 seconds 1:M 03 Mar 2024 13:49:34.797 * Opening AOF incr file appendonly.aof.1.incr.aof on server start 1:M 03 Mar 2024 13:49:34.797 * Ready to accept connections tcp 1:M 03 Mar 2024 13:54:35.012 * 100 changes in 300 seconds. Saving... 1:M 03 Mar 2024 13:54:35.013 * Background saving started by pid 75 75:C 03 Mar 2024 13:54:35.636 * DB saved on disk 75:C 03 Mar 2024 13:54:35.637 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB 1:M 03 Mar 2024 13:54:35.722 * Background saving terminated with success 1:M 03 Mar 2024 13:59:36.060 * 100 changes in 300 seconds. Saving... 1:M 03 Mar 2024 13:59:36.061 * Background saving started by pid 135 135:C 03 Mar 2024 13:59:36.775 * DB saved on disk 135:C 03 Mar 2024 13:59:36.776 * Fork CoW for RDB: current 0 MB, peak 0 MB, average 0 MB 1:M 03 Mar 2024 13:59:36.863 * Background saving terminated with success 1:M 03 Mar 2024 14:04:37.033 * 100 changes in 300 seconds. Saving... 1:M 03 Mar 2024 14:04:37.034 * Background saving started by pid 199 199:C 03 Mar 2024 14:04:37.353 * DB saved on disk 199:C 03 Mar 2024 14:04:37.354 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB 1:M 03 Mar 2024 14:04:37.436 * Background saving terminated with success 1:M 03 Mar 2024 14:06:59.035 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis. 1:M 03 Mar 2024 14:08:21.029 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis. 1:M 03 Mar 2024 14:09:38.093 * 100 changes in 300 seconds. Saving... 1:M 03 Mar 2024 14:09:38.093 * Background saving started by pid 255 255:C 03 Mar 2024 14:09:38.658 * DB saved on disk 255:C 03 Mar 2024 14:09:38.660 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB 1:M 03 Mar 2024 14:09:38.696 * Background saving terminated with success 1:M 03 Mar 2024 14:11:33.051 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis. 1:M 03 Mar 2024 14:13:15.031 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

I think the MixPost project is great and I'm also thinking of a paid subscription. As it is, I prefer to use other solutions in the meantime. I hope it will be useful.

[L4ma]

I have the same problem as @DominArsen. I tried the installation on my Synology DS220+. I would love to use it.

[uhlhosting]

A simple reminder, this is open source, you are free to submit a PR that will add support for this. Or use the https://roadmap.mixpost.app to submit the feature request as it should.

[luckydonald]

> internal server error > feature request

[uhlhosting]

internal server error > feature request

?

[lao9s]

This is not a bug. We have not tested on NAS systems and do not support it. Users are responsible for deployment. We documented 3 methods:

• Standalone php app
• Laravel package app
• Docker Image