Troubleshooting MariaDB-Server Installation on Debian: "MariaDB/MySQL Server Running" Error

The "MariaDB/MySQL server running" error during installation on Debian usually occurs because an instance is already active, often triggered by Akonadi or a previous failed stop command. You must identify and terminate the conflicting process using ps aux | grep mysql, then remove stale lock files in /var/run/mysqld/ before restarting the service to complete the package installation successfully.

Understanding the Conflict Source

When you attempt to install mariadb-server via apt, the package manager runs post-installation scripts that try to start the database daemon. If the system detects that a MySQL-compatible server is already listening on the expected ports or holds specific PID files, it aborts the configuration phase with the error message indicating the server is running. This is a safety mechanism to prevent data corruption from multiple instances accessing the same data directory simultaneously. A common culprit on desktop-oriented Debian installations is the Akonadi framework. Akonadi is a personal information management framework used by applications like Kontact or KMail. It creates its own embedded MariaDB/MySQL instance for storing contacts, emails, and calendar data. Even if you are not actively using these KDE applications, the Akonadi service may have been started automatically or left in a zombie state after a previous crash. This hidden instance occupies the resources that the main mariadb-server package needs, leading to the conflict. Another frequent cause is a previous installation attempt that was interrupted. If the systemctl service was stopped but the PID file or socket file was not cleaned up properly, the new installation script interprets the presence of these files as evidence that the server is still running. In this scenario, no actual process is consuming CPU or memory, but the logical state of the system prevents further configuration. If you are managing a server environment rather than a desktop, check for orphaned processes from older MySQL versions. Sometimes, upgrading from MySQL 5.7 to MariaDB 10.x can leave residual processes if the transition was not handled cleanly. Understanding whether the conflict is due to an active application like Akonadi or a stale file state is crucial for choosing the correct remediation step. For broader context on package management issues in Debian, see our guide on Unable to Install Packages on Debian Linux.

Identifying Running Processes

Before attempting to kill any processes, you need to verify exactly what is running. Open a terminal and execute the following command to list all processes containing "mysql" or "mariadb":

ps aux | grep -i mysql

Look for entries that show the actual binary path. A typical entry might look like /usr/sbin/mysqld or akonadi_mysqld. Note the Process ID (PID) in the second column. If you see multiple entries, pay close attention to the user running them. System services typically run under the mysql user, while Akonadi instances might run under your regular user account. It is important to distinguish between the client tools and the server daemon. Lines showing grep -i mysql are just your search command and should be ignored. Focus on lines where the command starts with /usr/sbin/mysqld or similar paths. If you find a process owned by your current user, it is highly likely to be Akonadi. If it is owned by the mysql user, it is the main database server. You can also check which ports are being listened on to confirm the server's activity. Use the following command:

sudo ss -tlnp | grep mysql

Or alternatively:

sudo netstat -tlnp | grep mysql

If port 3306 is listed, a server is actively listening. The output will show the PID and program name associated with that port. This confirms that the service is not just holding a file, but is actually consuming network resources.

Stopping Conflicting Services

Once you have identified the source, you need to stop it gracefully. If the process is the main MariaDB service managed by systemd, use the standard service control commands. First, try to stop the service normally:

sudo systemctl stop mariadb

If this fails or returns an error stating the service is not found, it might be named mysql instead, depending on the package version or symlinks. Try:

sudo systemctl stop mysql

After stopping the service, verify that it is no longer running by checking the status:

systemctl status mariadb

If the issue is caused by Akonadi, stopping the main MariaDB service will not help because Akonadi manages its own instance. You need to stop the Akonadi backend specifically. Run:

akonadictl stop

This command sends a shutdown signal to the Akonadi server, which in turn stops its embedded MySQL instance. Wait a few seconds to ensure the process has terminated completely. You can verify this by running the ps aux | grep mysql command again; the Akonadi-related processes should be gone. In cases where the process does not respond to graceful shutdown signals, you may need to force termination. Identify the PID from the earlier ps aux output and use the kill command. Start with kill [PID]. If the process persists, use kill -9 [PID] as a last resort, though this is generally discouraged as it does not allow for clean data flushing.

Cleaning Up Stale Files

Even after stopping the processes, the installation script may still fail if lock files or socket files remain in the filesystem. These files are created when the server starts and are supposed to be removed upon shutdown. If the shutdown was abrupt or crashed, these files persist. Navigate to the runtime directory for MySQL/MariaDB:

cd /var/run/mysqld

List the contents to see if there are any leftover files:

ls -la

Look for files such as mysqld.pid, mysqld.sock, or mysql.sock. If these files exist and the corresponding processes are confirmed to be stopped, you can safely delete them. Remove them using:

sudo rm mysqld.pid mysqld.sock mysql.sock

Ensure that the directory permissions are correct. The mysqld directory must be owned by the mysql user and group. If the ownership is incorrect, the new installation may fail to create new sockets. Fix permissions with:

sudo chown mysql:mysql /var/run/mysqld

sudo chmod 755 /var/run/mysqld

Similarly, check the data directory for any stray lock files, although these are less commonly the cause of startup conflicts during installation. The primary focus should be on the runtime directory.

Reinstalling the Package

With the processes stopped and files cleaned, you can now retry the installation. If the initial installation failed midway, the package might be in a half-configured state. It is best to purge the package and reinstall it to ensure a clean slate. First, remove the partially installed package:

sudo apt-get purge mariadb-server

Then, update the package cache and install fresh:

sudo apt-get update

sudo apt-get install mariadb-server

During the installation, the post-installation scripts should now succeed in starting the service because no other instance is blocking it. Monitor the terminal output for any errors. If the installation completes successfully, verify the service status:

systemctl status mariadb

You should see an "active (running)" status. You can also test the connection by running:

mysql -u root -p

Enter the root password if one was set during installation. Successful login confirms that the troubleshooting steps were effective.

Frequently Asked Questions

Why does Akonadi interfere with MariaDB installation?

Akonadi uses its own embedded MariaDB/MySQL instance to store personal data for KDE applications. This instance runs independently of the system-wide MariaDB service and can conflict during installation if it is already active or left in a zombie state.

How do I know if a MySQL process is actually running?

Use ps aux | grep mysql to list processes. If you see a line with the binary path (e.g., /usr/sbin/mysqld) and a valid PID, the process is running. Ignore lines that only contain "grep".

Is it safe to delete files in /var/run/mysqld?

Yes, provided that the MySQL/MariaDB service is completely stopped. These files are runtime artifacts like PIDs and sockets that should be recreated when the service starts. Deleting them while the service is running will cause the service to crash.

What if sudo systemctl stop mariadb says unit not found?

This indicates the service might be named differently, such as mysql, or the package was not fully installed. Try stopping mysql instead, or check installed packages with dpkg -l | grep maria.

Can I skip stopping Akonadi if I don't use KDE apps?

No, because Akonadi may have been installed as a dependency for other software or started automatically. Even if you don't use it, the background process can still block the MariaDB installation script.