MySQL Service Control Failure: Troubleshooting /etc/init.d/mysql Issues on Debian Etch


1 views

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