Fix MySQL Service Failing to Stop or Start (mysqld failed)

System administrators and developers taking over existing Linux servers often run into issues controlling the database service. When trying to stop or restart the service, the command line throws an error such as Stopping MySQL database server: mysqld failed! or Job for mysql.service failed, even though the database process is clearly running and accepting connections. This guide covers why service control scripts fail to stop or start MySQL or MariaDB processes and how to safely regain control of your database server on modern Linux distributions.

Quick fix

1. Ensure you are running the service command with root permissions using sudo.
2. Use modern service manager commands (sudo systemctl stop mysql or sudo systemctl stop mariadb) rather than legacy SysVinit scripts in /etc/init.d/.
3. If administrative shutdown authenticates via missing credentials or socket mismatches, check the error log using sudo tail -n 50 /var/log/mysql/error.log or sudo journalctl -xeu mysql.
4. If the process is frozen and non-responsive to clean shutdown commands, locate the process ID (PID) and send a standard termination signal using sudo kill PID (avoid kill -9 unless necessary).
5. Remove stale process ID files left behind in /var/run/mysqld/ before starting the service again.

Why this happens

• Outdated init script usage: Modern Linux operating systems (such as Debian, Ubuntu, AlmaLinux, and Rocky Linux) use systemd to manage processes. Calling /etc/init.d/mysql directly relies on backward-compatibility wrappers that frequently fail to pass credentials or capture process states correctly.
• Authentication failure during shutdown: Init scripts and service managers execute shutdown routines by connecting to the database internally (historically via system maintainer accounts like debian-sys-maint or unix socket authentication). If passwords change, config files are edited incorrectly, or permissions on /etc/mysql/debian.cnf are changed, shutdown commands fail.
• Orphaned process or stale PID file: If MySQL crashed or was terminated forcefully in the past, a leftover process ID file (such as /var/run/mysqld/mysqld.pid) might remain on disk. The init script attempts to signal a PID that either no longer exists or points to an unrelated process.
• Stuck transactions or unwritten buffer pool: When MySQL is busy writing dirty pages from the InnoDB buffer pool to disk or waiting on locked tables, standard shutdown scripts may hit a timeout limit and report a failure message while mysqld is still attempting a graceful flush.
• Socket file permission issues: The daemon needs write access to Unix socket files located in /var/run/mysqld/ or /tmp/. Incorrect file ownership prevents administrative utilities from connecting to signal a shutdown.

How to fix it

Before modifying configuration files or terminating processes, ensure you back up your database files. If the database engine is active, take a full database dump using mysqldump or back up your data directory if the service is completely stopped.

1. Switch to modern systemd commands with standard privileges

Executing service management scripts from a regular user account or using legacy /etc/init.d/ scripts leads to permission errors. Always execute commands using sudo or directly as the root user.

Use systemctl to manage the database service on modern Linux systems:

# Check the current status of the service
sudo systemctl status mysql

# Stop the MySQL service safely
sudo systemctl stop mysql

# Start the MySQL service
sudo systemctl start mysql

# Restart the MySQL service
sudo systemctl restart mysql

If your distribution uses MariaDB instead of MySQL, replace mysql with mariadb in the commands above:

sudo systemctl status mariadb
sudo systemctl stop mariadb

2. Diagnose authentication errors in management configuration

On Debian and Ubuntu distributions, local init and systemd scripts use an internal maintenance configuration file located at /etc/mysql/debian.cnf to issue graceful shutdown commands through the local Unix socket. If the credentials inside this file do not match the database root account or internal system user, shutdown scripts report mysqld failed!.

Inspect the credentials in the file using root privileges:

sudo cat /etc/mysql/debian.cnf

The file contains user and password fields used by maintenance scripts:

[client]
host     = localhost
user     = debian-sys-maint
password = example_generated_password
socket   = /var/run/mysqld/mysqld.sock

[mysqladmin]
host     = localhost
user     = debian-sys-maint
password = example_generated_password
socket   = /var/run/mysqld/mysqld.sock

If the debian-sys-maint user was dropped or its password changed inside the database, restore access by logging into MySQL as root:

sudo mysql -u root

Re-create or update the maintenance user inside the MySQL prompt to match the credentials listed in /etc/mysql/debian.cnf:

ALTER USER 'debian-sys-maint'@'localhost' IDENTIFIED BY 'example_generated_password';
GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;
EXIT;

After updating the database privileges to match the configuration file, try stopping the service using sudo systemctl stop mysql.

3. Handle hung processes and stale PID files

If the service command hangs indefinitely or reports immediate failure because a daemon process is unresponsive, you must identify the running process and terminate it gracefully.

Find the process ID of the running mysqld daemon:

ps aux | grep mysqld

Look for lines showing /usr/sbin/mysqld. Note the process ID (the number in the second column, such as 12345).

Send a standard termination signal (SIGTERM) to allow MySQL to flush data to disk and close table locks cleanly:

sudo kill 12345

Monitor the error log while the process shuts down. Do not forcefully kill the process immediately, as InnoDB recovery can take time for large datasets:

sudo tail -f /var/log/mysql/error.log

If the process refuses to stop after several minutes and log activity has ceased completely, issue a forceful kill signal (SIGKILL):

sudo kill -9 12345

After the process terminates, check for stale socket and PID files that prevent systemd from restarting the daemon:

sudo rm -f /var/run/mysqld/mysqld.pid
sudo rm -f /var/run/mysqld/mysqld.sock

Ensure the directory ownership is set to the mysql system user:

sudo chown -R mysql:mysql /var/run/mysqld/

Start the database service cleanly:

sudo systemctl start mysql

4. Check disk space and system logs

A full disk partition prevents MySQL from writing its PID file or updating system tables, causing service stop and start routines to fail.

Check available storage on your root and data partitions:

df -h

If space is at 100%, free up disk space by clearing archived system logs or temporary files before starting MySQL. You can also refer to our guide on how to kill slow MySQL queries automatically to prevent runaway transactions from filling up temporary tables on disk.

Check that it worked

Confirm that the service is running, responsive, and managed cleanly by systemd.

First, verify the active status of the unit:

sudo systemctl status mysql

The output must display active (running) in green text without warning lines regarding failed shutdown actions.

Next, test local database administrative connectivity using mysqladmin:

sudo mysqladmin -u root ping

The output should return:

mysqld is alive

Finally, perform a test restart to verify that init scripts start and stop the daemon without throwing errors:

sudo systemctl restart mysql

Prevent it next time

• Use systemctl exclusively: Avoid mixing legacy /etc/init.d/mysql scripts with modern systemctl commands to prevent state tracking mismatch in the init system.
• Keep maintenance credentials intact: Do not remove internal system users like debian-sys-maint or modify /etc/mysql/debian.cnf unless you update matching privileges inside the database engine.
• Monitor disk usage and log size: Configure log rotation and set up storage alerts to ensure MySQL always has free disk space to write binary logs, sockets, and lock files.
• Avoid forced kills: Never use kill -9 on a database process unless standard shutdown procedures hit a complete deadlock. Unclean shutdowns leave corruption flags on tables and lock files on disk.

FAQ

Why does /etc/init.d/mysql stop fail while mysqladmin shutdown works?

The /etc/init.d/mysql wrapper relies on configuration files like /etc/mysql/debian.cnf to authenticate shutdown requests automatically. If those files have incorrect passwords or missing socket permissions, the wrapper fails. Conversely, running mysqladmin shutdown manually uses your current shell privileges or direct database credentials, bypassing the broken script config.

Is it safe to delete the mysqld.sock file manually?

It is only safe to delete mysqld.sock when the mysqld process is completely stopped. If you delete the socket file while MySQL is actively running, existing client applications will lose local connectivity, and you may have to restart the database server to recreate the socket file.

What is the difference between stopping mysql and mariadb services?

MySQL and MariaDB are separate implementations of relational database servers. On Linux distributions that install MariaDB by default (such as recent versions of Debian, Ubuntu, and CentOS/RHEL), the service is named mariadb.service, though a symlink for mysql.service often exists. Using sudo systemctl stop mariadb directly targets the systemd unit without relying on alias resolution.

How do I stop MySQL if systemctl hangs indefinitely?

If systemctl stop mysql hangs, MySQL is usually flushing large amounts of dirty data from memory to disk or waiting for pending transactions to complete. Open a separate terminal window and monitor /var/log/mysql/error.log. If disk write activity is ongoing, allow the process time to finish. If no log activity occurs, inspect running processes using ps aux | grep mysqld and send a SIGTERM signal using the kill command.

Managed Database Hosting with Dhruva Cloud

Managing raw database daemons, maintenance users, systemd units, and socket files requires ongoing server maintenance. Dhruva Cloud simplifies database management by providing built-in phpMyAdmin access, Web Terminal tools, automated backups, and optimized storage infrastructure. Every site hosted on Dhruva Cloud runs behind an active Cloudflare CDN with automated SSL, DDoS protection, and high-performance NVMe solid-state drives, allowing developers to focus on writing code rather than troubleshooting failed daemon scripts.