MariaDB Startup Issue Resolved
I encountered a common but critical issue where the MariaDB service failed to start on my system. The initial error message from systemctl was generic, stating that the mariadb.service had failed because the control process exited with an error code.
Job for mariadb.service failed because the control process exited with error code.
To diagnose the problem, I first checked the status of the service and the system journal, which provided slightly more detail but still wasn't the root cause. The output mentioned exit-code and Operation not permitted, hinting at a permissions issue.
The crucial step was to examine the MariaDB error log. By running a command like tail /var/log/mariadb/mariadb.log, I found the specific cause:
[ERROR] InnoDB: Operating system error number 13 in a file operation.
[ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
[ERROR] InnoDB: Cannot open datafile './ibtmp1'
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
This confirmed that the MariaDB daemon, which runs as the mysql user, did not have the necessary permissions to access its data directory, typically /var/lib/mysql. The mysqld process was denied access to create a temporary file, which caused the InnoDB storage engine to fail, and consequently, the entire service aborted.
I then verified the ownership of the /var/lib/mysql directory using ls -ld /var/lib/mysql. The output showed that the directory was incorrectly owned by root, not mysql.
drwxr-xr-x 1 root mysql 4096 Aug 12 05:48 /var/lib/mysql
To resolve the issue, I used the chown command to recursively change the ownership of the directory to the mysql user and group:
sudo chown -R mysql:mysql /var/lib/mysql
After running this command, which grants the mysql user full access to its data files, I successfully started the MariaDB service: sudo systemctl start mariadb
This case highlights the importance of checking application-specific logs in addition to system logs when troubleshooting service failures. While systemd provides general status information, the application's own logs often contain the detailed error messages needed to pinpoint the exact problem, especially with permissions-related issues.
Top comments (0)