Problem with MariaDB

Admin Talk Upgrade
1

My Setup:

  • Hardware or environment you use: VM running Ubuntu 24.04 LTS on Proxmox VE.
  • SeaTable Edition: Enterprise
  • SeaTable Version (only necessary for self-hosted): 5.3.10

Describe the Problem/Error/Question:

I am attempting to set up a new SeaTable Enterprise instance on a VM running Ubuntu 24.04 LTS using the official seatable-compose setup. While most services start correctly, the MariaDB container consistently fails to start with the MARIADB_AUTO_UPGRADE environment variable set to its default value (or 1). This issue prevents the entire SeaTable stack from becoming operational, as seatable-server reports dependency failed to start: container mariadb is unhealthy.

Interestingly, I have successfully deployed SeaTable Enterprise 5.3.10 on another VM with an identical Ubuntu 24.04 LTS setup, where MARIADB_AUTO_UPGRADE works as expected. This suggests the problem might be specific to this particular VM’s environment or data volume.

My current workaround (which allows SeaTable to run) is to set MARIADB_AUTO_UPGRADE=0 in custom-seatable-server.yml. When set to 0, MariaDB starts and becomes healthy, and the entire SeaTable stack functions correctly. However, I want to resolve the underlying issue with MARIADB_AUTO_UPGRADE for future stability and cleaner upgrades.

Steps taken:

  1. Initial sudo docker compose up -d with default/MARIADB_AUTO_UPGRADE=1 in custom-seatable-server.yml.
  2. Observed mariadb container failing.
  3. Changed MARIADB_AUTO_UPGRADE to 0 in custom-seatable-server.yml.
  4. sudo docker compose down
  5. sudo docker compose up -d
  6. SeaTable functions correctly with MARIADB_AUTO_UPGRADE=0.

Troubleshooting attempts when MARIADB_AUTO_UPGRADE=1:

  • Increased start_period for mariadb service to 960s.
  • Attempted to manually run mysql_upgrade inside the mariadb container via sudo docker exec -it mariadb bash. The mysql_upgrade command was not found in $PATH (command not found) and was also not found at common locations like /usr/bin/mysql_upgrade or /usr/local/bin/mysql_upgrade using find.
  • Attempted to use /usr/local/bin/healthcheck.sh --mariadbupgrade but this script did not accept --user and --password arguments as expected, leading to unknown option errors.

Error Messages:

When MARIADB_AUTO_UPGRADE is enabled (default or 1), the mariadb container’s logs show the following critical error message during its startup sequence, even after reporting “ready for connections”:

2025-06-21 12:15:26+02:00 [ERROR] [Entrypoint]: Unable to start server.

Additionally, the MariaDB logs consistently show a warning related to cgroups:

2025-06-21 12:14:49+02:00 [Warn] [Entrypoint]: /sys/fs/cgroup///memory.pressure not writable, functionality unavailable to MariaDB

The docker compose ps output indicates:

✘ Container mariadb Error dependency failed to start: container mariadb is unhealthy

I appreciate any help or insights the community can provide, and thank you in advance for your time!

2

I think we can agree, that this is not a SeaTable but a mariadb Problem, right?
Still, I would try with these debugging steps:

Troubleshooting Steps

  1. Check MariaDB Logs for Upgrade Errors:
    Inspect the full MariaDB container logs for more details about why the auto-upgrade is failing. Look for messages related to failed schema upgrades or missing tools.
  2. Inspect Data Volume:
    If possible, examine the MariaDB data directory for corruption or inconsistencies. You may need to back up and then reset the data volume if corruption is suspected.
  3. Check for Missing Tools:
    As you noted, mysql_upgrade is missing from the container’s $PATH. This is highly unusual for a standard MariaDB image and could indicate a problem with the image being used, or a custom entrypoint that expects a different environment.
  4. Compare with Working VM:
    Compare the exact Docker image tags, data volumes, and environment variables between the working and non-working VMs. Even minor differences can be significant.
  5. Test with a Clean Data Volume:
    Try starting the stack with a fresh data volume (after backing up any important data) to see if the issue persists. If the problem goes away, the original data volume may be the cause.
  6. Check Healthcheck Scripts:
    The healthcheck script for MariaDB may be failing due to the auto-upgrade issue. Review the script’s logic and ensure it correctly reports health when the upgrade process is incomplete or fails.
3

Update on my MariaDB upgrade issue with SeaTable on Ubuntu 24.04 and MariaDB 11.4.3.

Initially, I experienced problems starting MariaDB when the MARIADB_AUTO_UPGRADE environment variable in my custom-seatable-server.yml was set to its default value (or 1). MariaDB would fail with the error [ERROR] [Entrypoint]: Unable to start server. A workaround involving setting MARIADB_AUTO_UPGRADE=0 allowed MariaDB to start and the SeaTable stack to function, but this was not a permanent solution.

To diagnose the root cause, I conducted a detailed comparison between the problematic VM and a functioning production VM, analyzing various system and software components:

  • custom-seatable-server.yml (excluding the workaround and Nginx deactivation)
  • MariaDB Docker Image Tags
  • Main Compose file (seatable-server.yml)
  • Linux Kernel Version
  • Docker Engine Version
  • MariaDB Volume Host Path (which turned out to be /opt/mariadb on both, not the expected /opt/seatable-compose/volumes/mariadb)
  • Filesystem Type and Mount Point of the MariaDB Volume
  • Permissions and Ownership of the MariaDB Volume Directory

The result was both surprising and relieving: All compared system and software components were found to be virtually identical on both VMs. The minor differences (e.g., the effective mount path for the MariaDB volume) were consistent across both systems, indicating they were not the root cause.

The Crucial Finding and Solution

Since the environments were identical, it strongly suggested that the problem lay with the content of the existing MariaDB data volume itself. Apparently, the data or metadata within the old MariaDB volume on the problematic VM (likely created with an older MariaDB version) was preventing the MARIADB_AUTO_UPGRADE=1 process from completing successfully during the migration to MariaDB 11.4.3. The cgroup and io_uring warnings, while present, were not critical enough to prevent the server from starting once the data volume was clean.

The solution was to create a brand-new, empty MariaDB data volume and restart the stack:

  1. Shut down the stack and remove the MariaDB data volume on the problematic VM: (IMPORTANT: Ensure you have a recent backup, as this will delete all MariaDB data!)Bashcd /opt/seatable-compose/ sudo docker compose down -v(The -v parameter is crucial here to remove the volumes.)
  2. Adjust custom-seatable-server.yml: I reverted MARIADB_AUTO_UPGRADE back to 1 and re-enabled the Nginx configuration:`YAML - MARIADB_AUTO_UPGRADE=1
  3. Restart the stack:Bashsudo docker compose up -d

After performing these steps, the MariaDB container started successfully, completed the mariadb-upgrade process without errors, and transitioned to a (healthy) state. Subsequently, the seatable-server container also started correctly.

Outcome

With MariaDB and the SeaTable server successfully started, I was able to access the SeaTable instance via the VM’s IP address in my browser and proceed with the initial setup (creating an administrator account, configuring the database connection).

Conclusion: The issue was a database migration problem caused by the data within the old MariaDB volume. A clean start with a new volume resolved the problem entirely.

I hope these findings are helpful to others who might encounter similar issues!

4

Thanks to you for taking the time to document your “journey”.