Error establishing a database connection on WordPress Blog

I have to admit that I do not really regularily write into this blog. Usually, whenever I have an idea, I write down a first draft and finish the post later, sometimes weeks later. Some days ago I had such an idea and realized that the blog was completely unreachable. Not sure for how long actually. The only thing it showed was this error saying “Error establishing a database connection” (see image below).

Update: If you are lucky, everything is a little easier to fix as described in my older article: https://mic.st/blog/how-to-fix-error-establishing-a-database-connection-for-wordpress/

Investigating the error

As nothing did work anymore from a frontend perspective, I quickly went into the webserver to find out what’s going on.

First of all, it was years ago since setting up the wordpress website so I was not even aware which kind of database was actually supposed to run. After finding out that it’s “mariadb”, I just wanted to try restarting the database service. A quick Google search lead to this: https://mariadb.com/docs/server/service-management/operations/start-stop-status/

Restarting can be done using:

sudo systemctl restart mariadb

Unfortunately, this just did not work. It exited with following error:

Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.Code language: Bash (bash)

As mentioned in the error, running systemctl status mariadb.service can give you a little more information about what did actually go wrong. As the error itself is not really giving you a lot.

The error mentioned something regarding not enough space left. Which was a relieve as it sounded like I can just delete some files and everything should work again.

I found out that the drive was actually pretty full. You might be able do that via your server panel (which I initally did) or you can run the following:

df -h

The -h argument does just mean “human readable”. You will get a nice output about your drives and space used which does give you a first indication of where you should free up some space. My main drive did show around of 99% space used, which obviously is a little too much. A little more about this command you can find here for example: https://opensource.com/article/18/7/how-check-free-disk-space-linux

Where to save space?

To gain more insights on where to actually save space, it does make sense to have a look on the directories themselves. The command line tool ncdu (see https://dev.yorhel.nl/ncdu) is of great use here as you quickly gain insights on where space is used. It is a fast and interactive tool. However, it is probably not installed by default with your Linux distribution. In my case I was not able to install it as that much space was taken by “whatever” (as I still did not know).

Find space used without ncdu

Of course you can also find out about space used without ncdu. For finding out about directories themselves, you can use du or more specifically du -hs to find out about the size of a given directory. It is using the one you are currently in if no path is passed.

A good starting point is using:

 du -h --max-depth=1 / | sort -h

It gives you the file size of anything located under / going down with a depth of one (as you do not want to the size of each and every directory on your filesystem). It is sorted so that you can easily spot the largest directory. Which in my case was var.

You can go down then directory by directory until finding out what is taking most space.

Delete stuff

If you are not aware of what the stuff is you intend to delete: Google first! You can easily break your system by deleting the wrong things. Also consider doing a backup first via your webserver provider before deleting anything.

Some ideas for stuff to delete:

• Unused docker containers
• old log files (they can take up a huge amount if never cleaned up!). Do not delete any mysql related logfiles for now!
• Cronjob output (this was a couple of gigabytes in my case, I also removed the associated cronjob as it was not needed anyways)

Trying to restarting the database service

I cleaned up a lot and tried restarting and… it still did not work.

Now it is time to have a closer look into the mysql logs. Their location is depending on your setup. You can find out the location via mysqld --print-defaults

In my case they were located under /var/log/mysql/error.log.

The log file included this:

2025-05-09 15:18:59 0 [ERROR] Aria engine is not enabled or did not start. The Aria engine must be enabled to continue as mysqld was configured with --with-aria-tmp-tables
2025-05-09 15:18:59 0 [ERROR] AbortingCode language: CSS (css)

After a quick Google search I found that it might be fixed when renaming a certain “aria” file. More information on this can be found here: https://support.plesk.com/hc/en-us/articles/12377243101591-MariaDB-fails-to-start-Aria-engine-is-not-enabled-or-did-not-start

It works!

And now… By using sudo systemctl restart mariadb restarting works 🚀 Hooray!

The blog and everything is accessible again, no data seems to be lost. Peeew!

Conclusion or what did we learn

1. Have backups in place
2. Pay attention to the space used on your webserver
   • It might just crash, service might shutdown and things might be unable to be restared
3. Watch out for Cronjobs running wild. Check regularily or ideally set them up so that they cannot really clog your space
4. Do install ncdu now if you do not have already. It is a great tool saving you a lot of time.
5. Really do google any file or directory you want to delete and are not sure about. It is easy to break stuff.

Hope you learned something today, happy webserver debugging!