If you’ve ever tried to start your MariaDB or MySQL service on an Ubuntu server (especially on managed platforms like RunCloud) only to be met with a silent failure, you know the stress. One of the most cryptic reasons for this is Errcode: 28 “No space left on device”. At CODE TOT, we’ve encountered this during midnight maintenance many times, and the fix requires more than just deleting a few files—it requires a sustainable cleanup strategy.
Tested & Verified: This guide is based on a real-world incident handled by our DevOps team on a production RunCloud server running Ubuntu 22.04 and MariaDB 10.11. We recovered 15GB of space and prevented recurrence in under 10 minutes.
1. Diagnosing the MariaDB Error Log
When MariaDB won’t start, don’t guess. Check the direct reason in the error log located at /var/log/mysql/error.log. Use this command to see the latest crash reason:
sudo tail -n 50 /var/log/mysql/error.log | grep "Errcode: 28"If you see [ERROR] mariadbd: Error writing file './ddl_recovery.log', your database is dead-locked because it can’t even write its own heartbeat file.
2. Identifying the Space Hogs
Run df -h and look for any partition at 100%. If / or /var is full, use our favorite troubleshooting one-liner to find the top 5 largest directories:
sudo du -cha --max-depth=1 /var | sort -hr | head -n 53. The 3-Step Emergency Cleanup
Step A: Purge Rotated Logs
Years of unmanaged logs can eat gigabytes. Safely delete any log that has already been rotated (ending in .gz or .1):
sudo find /var/log -type f -regex ".*.gz$" -delete
sudo find /var/log -type f -regex ".*.1$" -deleteStep B: Clear APT & Systemd Caches
sudo apt-get clean
sudo journalctl --vacuum-time=3dStep C: Manage Database Binary Logs
If MariaDB finally starts, jump into the shell and purge the binlogs. These are solely for replication and point-in-time recovery; if you have a nightly backup, you can safely trim them:
mysql -u root -p -e "PURGE BINARY LOGS BEFORE NOW();"4. Preventing the “Full Disk” recurrence
To ensure your server never hits 100% again, update your MariaDB configuration at /etc/mysql/mariadb.conf.d/50-server.cnf with these production-hardened variables:
- binlog_expire_logs_seconds = 604800 (7 days)
- max_binlog_size = 100M (Prevents massive single log files)
Conclusion
Fixing Errcode: 28 is a routine task for our infrastructure team at CODE TOT. By automating log rotation and vacuuming your journals, you maintain a healthy environment for your WordPress databases to thrive. If you’re tired of running out of space on your VPS, let us handle your WordPress Maintenance today.


