When standard service control commands fail while the MySQL process remains active, we're dealing with a classic Linux administration puzzle. The key indicators:
$ /etc/init.d/mysql stop
Stopping MySQL database server: mysqld failed!
Yet process inspection reveals MySQL is indeed running:
$ ps aux | grep mysql
root 2045 0.0 0.1 2676 1332 ? S Jun25 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 2082 0.6 10.7 752544 111188 ? Sl Jun25 18:49 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
While investigating the root cause, these immediate workarounds exist:
# Direct shutdown using mysqladmin (confirmed working)
$ mysqladmin shutdown
# Forceful kill approach (use with caution)
$ kill -TERM [mysqld_pid_from_ps_output]
$ /etc/init.d/mysql start
The Debian init script (/etc/init.d/mysql) typically fails when:
- PID file location mismatch (check /etc/mysql/my.cnf)
- Permission issues on /var/run/mysqld/
- Custom configurations overriding defaults
- MySQL was started outside the init system
Diagnostic commands:
# Verify PID file location
$ grep pid-file /etc/mysql/my.cnf
# Check directory permissions
$ ls -ld /var/run/mysqld/
# Test init script with debug
$ sh -x /etc/init.d/mysql stop
For production systems, implement these fixes:
# Reconfigure MySQL package (Debian specific)
$ dpkg-reconfigure mysql-server-5.0
# Verify package integrity
$ apt-get install --reinstall mysql-server
# Alternative startup method
$ service mysql restart --skip-grant-tables
For stubborn cases, examine these aspects:
# Check for zombie processes
$ ps aux | grep -i defunct | grep mysql
# Verify socket connections
$ netstat -tulpn | grep mysql
# Inspect systemd compatibility (if present)
$ systemctl status mysql.service
Remember to check MySQL error logs for additional clues:
$ tail -50 /var/log/mysql/error.log
When working with a Debian Etch server, you might encounter a situation where standard MySQL control commands fail:
# /etc/init.d/mysql stop
Stopping MySQL database server: mysqld failed!
Yet the process appears to be running normally when checked:
# ps aux | grep mysql
root 2045 0.0 0.1 2676 1332 ? S Jun25 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 2082 0.6 10.7 752544 111188 ? Sl Jun25 18:49 /usr/sbin/mysqld
The mysqladmin shutdown command might work as an alternative:
# mysqladmin shutdown
This suggests the MySQL service itself is healthy, but the init system interaction is broken.
First, verify your MySQL package installation status:
# dpkg --list mysql\*
ii mysql-client-5.0 5.0.32-7etch8 mysql database client binaries
ii mysql-server-5.0 5.0.32-7etch8 mysql database server binaries
Common causes for this behavior include:
- Missing or incorrect PID file location
- Permission issues on control sockets
- Corrupted init.d script
As a temporary workaround, you can stop MySQL manually:
# kill $(cat /var/run/mysqld/mysqld.pid)
# Or if PID file is missing:
# killall mysqld
Then verify the process has terminated:
# ps aux | grep mysql
To properly fix the init.d script behavior:
# apt-get --reinstall install mysql-server
# update-rc.d -f mysql remove
# update-rc.d mysql defaults
You can debug the init script by running it manually with increased verbosity:
# sh -x /etc/init.d/mysql stop
This will show exactly where the script fails during execution.
For newer Debian systems, consider using service instead:
# service mysql stop
Or directly invoking the safe_mysqld script:
# /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/run/mysqld/mysqld.sock --pid-file=/var/run/mysqld/mysqld.pid