I'm setting up the Memtly photo-sharing app with Docker Compose. I copied the MariaDB configuration from the setup documentation and changed the required passwords and keys, verifying them carefully. When I run `docker compose up -d`, the MariaDB container repeatedly restarts with an error saying the entrypoint script cannot find `mysqld` while checking the configuration:
`mariadbd failed while attempting to check config`
`command was: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --verbose --help`
`/usr/local/bin/docker-entrypoint.sh: line 105: mysqld: command not found`
I also initially had an `/etc/timezone` mount error, which disappeared after commenting out that volume. I already have another application using MariaDB on the same Docker host, so I stopped it and tried changing the port, but the same startup error remained. I've also run Docker system and volume pruning while testing changes.
Could the other MariaDB instance, the port configuration, or the timezone mount be causing this? I'm still fairly new to Docker and would appreciate help identifying the real problem. Updating the Memtly image from `latest` to MariaDB 10.9 eventually made the containers stay up.
3 Answers
Avoid relying on `latest` for database images. It can change underneath an existing compose file and introduce entrypoint or binary-name differences. Pin the version recommended by the application documentation, or use a fixed version you have tested, such as MariaDB 10.9 in this case. The `/etc/timezone` mount was a separate warning and was unlikely to cause `mysqld` to disappear.
The important part of the log is `mysqld: command not found`. The entrypoint script is trying to run the MySQL-compatible binary while checking its configuration, but that executable is not available in the image or its PATH. You can inspect `/usr/local/bin/docker-entrypoint.sh` inside the container, but changing the host port will not fix this particular error.
Using a specific, known-compatible MariaDB tag instead of `latest` is the right direction. The setup may have been written for an older image whose entrypoint expected `mysqld`, while a newer image expects or provides `mariadbd` instead.
The other MariaDB container should not affect this one unless both containers try to publish the same host port or use the same bind mount or named volume. A host-port conflict normally produces a bind error when Docker starts the container, rather than a missing-binary error inside it.
If the application and database share a Docker network, you usually don’t need to publish MariaDB’s port to the host at all. The application can connect to the database using the MariaDB service name and container port 3306.
That makes sense. Switching the Memtly database image from `latest` to `10.9` fixed the restart loop, so it looks like the issue was with the image/version rather than the other MariaDB container.
The two applications use different MariaDB images, and changing the Memtly one to 10.9 resolved it. That suggests the `latest` tag had compatibility problems with the compose configuration, not that both databases conflicted with each other.