Stuck on "Waiting for SQL"...

outofsight

I noticed that since about one month my Mailcow installation is not working anymore, likey after an update.

Doing the recommended
docker compose logs --tail=200 php-fpm-mailcow nginx-mailcow

show a repeating
Waiting for SQL...

The log of mysql doesn’t show any error and the
source mailcow.conf ; docker compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} ${DBNAME}
apparently succeds.

Any idea?

esackbauer

One idea is to search the forum:
https://community.mailcow.email/d/126-waiting-for-database-to-come-up

outofsight

It doesn’t seems the same issue because the sql client in my installation can connect withour access denied issue.

DocFraggle

Did you try restarting the stack?

docker compose down
docker compose up -d

outofsight

DocFraggle

yes, several times, no success

[unknown]

does this apply given that I have no access denied issue?

[unknown]

does that thread apply given I have no access denied issue?

[unknown]

to esakbauer:
does this apply given I don’t experience the “access denied issue”?
what part of that thread are you recommending exactly?

well, I don’t understand what’s happening but I was trying to quote and reply to esakbauser with all that repeated messages but these are not processed properly

TuotHash

I think I have the same issue, I was just writing the following new thread, but I need to sleep soon, so can’t continue debugging rn, I hope someone has an Idea, or maybe I have more infos tomorrow.
I was updating mailcow and applied:
MAJOR UPDATES to be applied:
2025-02 - mailcow/mailcow-dockerizedreleases/tag/2025-02
2025-03 - mailcow/mailcow-dockerizedreleases/tag/2025-03

And now I get the 502 What is happening screen, inspecting the logs, I could see that the php-fpm container is waiting for sql, which wouldn’t come up. I waited a while but it did not end up working.
Fortunately I made a backup, unfortunately I rolled it back already so I can’t share the detailed logs.
I’ll update it again now and let it take some more time, maybe I wasn’t patient enough.
Maybe the database update in 2025-02 fried it, idk.

The Server is on Rocky 9 btw,
Well here is my logs:
mysql-mailcow-1 | 2025-06-28 01:01:17+02:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.13+maria_ubu2204 started.
mysql-mailcow-1 | 2025-06-28 01:01:17+02:00 [Warn] [Entrypoint]: /sys/fs/cgroup///memory.pressure not writable, functionality unavailable to MariaDB
mysql-mailcow-1 | 2025-06-28 01:01:17+02:00 [Note] [Entrypoint]: Switching to dedicated user ‘mysql’
mysql-mailcow-1 | 2025-06-28 01:01:17+02:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.13+maria_ubu2204 started.
mysql-mailcow-1 | 2025-06-28 01:01:17+02:00 [Note] [Entrypoint]: MariaDB upgrade (mariadb-upgrade or creating healthcheck users) required, but skipped due to $MARIADB_AUTO_UPGRADE setting
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] Starting MariaDB 10.11.13-MariaDB-ubu2204 source revision 8fb09426b98583916ccfd4f8c49741adc115bac3 server_uid 3Pws4BgyEreCXleUPopu/Yrifj4= as process 1
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Number of transaction pools: 1
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Using SSE4.2 crc32 instructions
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Warning] mariadbd: io_uring_queue_init() failed with EPERM: sysctl kernel.io_uring_disabled has the value 2, or 1 and the user of the process is not a member of sysctl kernel.io_uring_group. (see man 2 io_uring_setup).
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: innodb_buffer_pool_size_max=24m, innodb_buffer_pool_size=24m
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Completed initialization of buffer pool
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Upgrading redo log: 96.000MiB; LSN=2443736
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: 128 rollback segments are active.
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Setting file ‘./ibtmp1’ size to 12.000MiB. Physically writing the file full; Please wait …
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: File ‘./ibtmp1’ size is now 12.000MiB.
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: log sequence number 2443736; transaction id 372592
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Warning] You need to use –log-bin to make –expire-logs-days or –binlog-expire-logs-seconds work.
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] Server socket created on IP: ‘0.0.0.0’.
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] Server socket created on IP: ‘::’.
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] InnoDB: Buffer pool(s) load completed at 250628 1:01:17
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [ERROR] Incorrect definition of table mysql.event: expected column ‘definer’ at position 3 to have type varchar(, found type char(141).
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [ERROR] mariadbd: Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
mysql-mailcow-1 | 2025-06-28 1:01:17 0 [Note] mariadbd: ready for connections.
mysql-mailcow-1 | Version: ‘10.11.13-MariaDB-ubu2204’ socket: ‘/run/mysqld/mysqld.sock’ port: 3306 mariadb.org binary distribution
php-fpm-mailcow-1 | Waiting for SQL…

The Server is on Rocky 9 btw,
Well here is my logs:

mariadbphpfpm.txt

4kB

esackbauer

Latest updates seem to have a problem with Rocky:
https://community.mailcow.email/d/5041-preparing-indefinitely/6

I would suggest you open an issue at github with your details, so that the devs can look into it.

esackbauer

Seems like this is a known problem of Rocky Linux and SELinux enabled, and is already being worked on:
mailcow/mailcow-dockerized6510

outofsight

esackbauer

I’m not on Rocky Linux, but yes, it seems a SELinux related issue, because disabling it, it is “solved”.
Could be something introduced at the end of May because my last received email was from end of may.
Waiting for an update, in the meanwhile..
Thanks