v2 beta - embedded mariadb fails to initialise #5279
Labels
Comments
CommanderStorm
added
the
releaseblocker
|
same error on previous 2 or 3 nightlies. |
|
Is it rootless image? If yes:
|
|
I am not using rootless, but there was also this recent change to remove |
|
2.0.0-beta.0 (not the rootless image) has same issue with embedded mariadb initialization. |
|
@high3eam @c3p0vsr2d2 I just enabled MariaDB log to console. You could try the |
|
@louislam I get this log output with nightly2 (non-rootless): Nightly2 log |
That is strange... Have to find a way to 100% reproduce this. I cannot reproduce it on my Linux machine. |
|
I have this same issue, its a fresh install of Bookworm on RPi5, running Portainer. version: '3.3'
services:
uptime-kuma:
image: louislam/uptime-kuma:beta
container_name: uptime-kuma
volumes:
- uptime-kuma:/app/data
ports:
- "3005:3001"
restart: unless-stopped
volumes:
uptime-kuma:I get the exact same: [MARIADB] INFO: Try to restart Embedded MariaDB as it is not stopped by user
[MARIADB] INFO: Starting Embedded MariaDB
[MARIADB] INFO: Waiting for Embedded MariaDB to start...This was a fresh install of UK not a migration. EDIT This is using beta-rootless 2024-10-30T22:35:58Z [MARIADB] INFO: Embedded MariaDB: /app/data/run/mariadb is not found, create one now.
2024-10-30T22:35:58Z [MARIADB] INFO: Starting Embedded MariaDB
2024-10-30T22:35:58Z [MARIADB] INFO: Embedded MariaDB is ready for connections
2024-10-30T22:35:59Z [MARIADB] INFO: Embedded MariaDB started
2024-10-30T22:35:59Z [MARIADB] INFO: Creating basic tables for MariaDB
2024-10-30T22:36:00Z [MARIADB] INFO: Created basic tables for MariaDB
2024-10-30T22:36:00Z [SERVER] INFO: Connected to the database
2024-10-30T22:36:00Z [MIGRATION] INFO: Migration server is running on http://localhost:3001
2024-10-30T22:36:00Z [DB] INFO: Migrating Aggregate Table
2024-10-30T22:36:00Z [DB] INFO: Getting list of unique monitors
2024-10-30T22:36:00Z [DB] INFO: Clearing non-important heartbeats
2024-10-30T22:36:00Z [DB] INFO: No data to migrate@louislam the above might help? |
@N0Klu3 Thanks for your hints! I just reproduce this issue on my Pi4 too. |
Can you confirm that beta-rootless should not have Embedded MariaDB working? As it seems to work just fine? If it does work, why use non-root over root? Seems like if it works, running it as beta-rootless would be the better options no? |
Since I implemented this feature last year, the migration guide which I prepared recently was wrong. (I just updated) It should work on both the rootless and the root images. Actually all issues are probably related to the file permissions. I try my best to handle it smoothly for everyone.
|
Perfect thank you! |
|
none of the latest root/rootless images work for me. |
|
It seems that I have fixed the issue in the |
I tested nightly2 and still have the problem with the built-in MariaDB. 👟 Reproduction steps: Here is the
|
|
The error changed but I also still have an issue with the embedded mariadb after repulling nightly2 on my Debian 12 amd64 host to try a fresh install: Docker Compose Log |
|
@homelab-alpha @high3eam Thanks, I also could reproduce on my another linux. |
|
i think i found the problem, the mariadb did not initiatized correctly. Free feel to try again the nightly build, but |
I can confirm that it is working now. See the logs. I have a question: I noticed the comment in
This suggests setting the owner to UID 1000 and GID 1000. However, not all systems start with UID 1000 and GID 1000. For example:
I might be wrong, but I'll also test it today on a Raspberry Pi 4 with Ubuntu Server 24.04.1 LTS (GNU/Linux 6.8.0-1013-raspi aarch64). I'll let you know the outcome. 👟 Reproduction steps: Here is the
|
I think it is OK, because it is the UID/GID of the Thank you for your testing! |
Thank you for the clarification! I’ll still go ahead and test it today on the Raspberry Pi 4. I’ll let you know how it goes. |
|
@louislam I can also confirm that it works with a As expected, the UID/GID for the persistent MariaDB storage outside the container is set to UID/GID 1000. While I don't think this is a significant issue, would it be possible to set the UID/GID as global variables so that they match the UID/GID of the host server itself, rather than the container? Or is that not feasible, or perhaps not practical? 👟 Reproduction steps: Here is the
|
|
Thanks, I merge the pr now.
I think it is not possible at the moment, because it used MariaDB's default initialization which only |
That's good to know. In that case, I will only use the external MariaDB from now on. Keep up the good work! 👍 |
1 task
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
📑 I have found these related issues/pull requests
none
🛡️ Security Policy
Description
Tried to create a new docker based uptime kuma instance with embedded mariadb, but mariadb cannot initialise properly and goes into start and stop loop.
👟 Reproduction steps
Create a new uptime kuma instance with docker using this docker compose file:
👀 Expected behavior
Uptime Kuma would finalise the initialisation of the embedded mariadb
😓 Actual Behavior
start and stop loop of mariadb
🐻 Uptime-Kuma Version
2.0.0-beta.0
💻 Operating System and Arch
Debian 12.7 amd64
🌐 Browser
Edge v130
🖥️ Deployment Environment
📝 Relevant log output
Docker compose log output (click to expand)
The text was updated successfully, but these errors were encountered: