Stalwart suddenly stopped connecting to mySQL

Questions
1

Your question

Hello there.

I have had my Stalwart stack (stalwart container + mySQL container) running in docker since June with no problems.

Everything was fine until 2 or 3 weeks or so ago. I realized I couldn’t access my instance’s web page, and so, when checking the logs, I realized there were a few logs saying a connection to the database couldn’t be established.

At the time I was using the image stalwartlabs/stalwart:v0.16, and I updated my instance to use stalwartlabs/stalwart:latest.

Right now, when I spin up my stalwart container there are the only two lines I get:

⚠️ Startup failed: Failed to create tables: MySQL error (store.mysql-error): reason = Input/output error: Input/output error: Connection refused (os error 111)
⚠️ Startup failed: Failed to create tables: MySQL error (store.mysql-error): reason = Input/output error: Input/output error: Connection refused (os error 111)

I already checked several things like docker networking and other basic troubleshooting.

Eventually I fixed the webpage’s problem by restarting the host machine, but after a day or so, I’m getting 502 Bad Gateway again, and the SQL problem persists.

The weird thing (or not), is that I can still receive and send emails just fine.

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Connection refused means the MySQL host resolved but nothing was listening on that port as seen from inside the Stalwart container. Stalwart can’t start without its data store, so it exits at startup, and the 502 is your proxy finding nothing behind it.

I’d start with docker ps -a and the MySQL container’s logs: a crash loop, a full disk or a long InnoDB recovery after an unclean shutdown all look like this from Stalwart’s side. If MySQL is up, check the data store host in /etc/stalwart/config.json. It should be the compose service name; a container IP changes when the container is recreated, which would also explain a reboot fixing it for a day. A healthcheck on MySQL plus depends_on: condition: service_healthy on Stalwart keeps it from starting before the database is ready (MySQL backend).

Mail can’t be going through a container that fails at startup, so what’s handling it? An old container from the v0.16 image still running would fit. Also, pin v0.16 again: latest will move to 1.0 when it’s released at the end of the month.