web-dev-qa-db-fra.com

le processus mysql ne peut pas être arrêté

J'ai récemment installé 5.5.28-29.2 Percona Server (GPL) version 29.2 dans un bureau Ubuntu 12.04 OS. J'ai essayé d'arrêter le serveur en utilisant différentes méthodes:

- Sudo /etc/init.d/mysql stop
- Sudo kill -9 pid
- mysqladmin -u root -p shutdown

Toutes ces méthodes arrêtent le processus, mais il démarre automatiquement après sa mort. J'ai vérifié syslog (/ var/log/syslog /) et me montre toujours la trace suivante:

Jan  4 17:50:44 kernel: [ 1915.494219] init: mysql main process (17311) killed by KILL signal
Jan  4 17:50:44 kernel: [ 1915.494245] init: mysql main process ended, respawning
Jan  4 17:50:44 kernel: [ 1915.500025] type=1400 audit(1357318244.557:48): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18458 comm="apparmor_parser"
Jan  4 17:50:46 /etc/mysql/debian-start[18501]: Upgrading MySQL tables if necessary.
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: Looking for 'mysql' as: /usr/bin/mysql
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: This installation of MySQL is already upgraded to 5.5.28, use --force if you still need to run mysql_upgrade
Jan  4 17:50:46 /etc/mysql/debian-start[18515]: Checking for insecure root accounts.
Jan  4 17:50:46 /etc/mysql/debian-start[18520]: Triggering myisam-recover for all MyISAM tables

Connaissez-vous la raison pour laquelle le processus redémarre automatiquement? Merci d'avance !!

mysqlubuntupercona
28
ljmelgui

J'avais exactement le même problème. L'exécution de la commande kill tuerait le processus, mais dans mon cas, elle continuerait à apparaître de nouveau sous un ID de processus différent.

La seule façon pour moi de comprendre comment l'arrêter définitivement était la suivante:

Sudo stop mysql

J'espère que cela pourra aider.

Source: http://www.itfromscratch.com/how-to-stop-the-percona-mysql-server/

61
The New Guy

Utiliser Sudo service mysql stop a fonctionné pour moi.

30
alessio

Voulez-vous tuer toutes les instances de MySQL? Essayez en tant que root:

 pkill mysqld;
17
Ray

Je vais deviner, mais mysqld peut être démarré via le script init mysql_safe, qui redémarre le serveur.

3
ESG

Pour ceux qui regardaient cela des années après les faits, j'avais un problème similaire que je venais de résoudre.

Apparemment, il y avait un deuxième script d'initiation appelé orig_mysql.conf qui existait dans le répertoire/etc/init avec le fichier mysql.conf. Cela a provoqué le démarrage récent de deux instances et, apparemment, la confusion s’est produite lorsqu’une a pris fin. En tant que tel un respawning continu a eu lieu.

Ma solution:

  1. Arrêtez mysql via upstart si possible: service mysql stop
  2. RETIREZ l’un des fichiers de configuration (j'ai supprimé le fichier /etc/init/orig_mysql.conf). Puis redémarrez init en utilisant: telinit u
  3. Éliminez tous les processus mysqld restants manuellement.

Une fois que vous avez confirmé que aucun processus mysqld n’est en cours d’exécution et qu’ils ne sont plus réactivés, redémarrez mysql avec service mysql start.

J'espère que ça aide quelqu'un. Il m'a fallu deux ans pour résoudre ce problème.

3
RobNY

Vous devriez juste enlever mysql.sock. De cette façon, relancer le service mysqld le recréera. Si ce n'est pas le cas, redémarrez simplement le serveur après avoir supprimé mysql.sock

0
Behrad Khodayar

Cela pourrait ne pas s'appliquer à ce problème particulier, mais ici, ça va quand même. J'ai vérifié le journal des erreurs ("/var/log/mysql/error.log") et constaté que "explicit_defaults_for_timestamp = TRUE" était à l'origine d'une erreur ("Variable inconnue"). Je l’ai donc supprimé de my.cnf ("/etc/mysql/my.cnf") et ai lancé "Sudo start mysql" et le système a été remis en service. J'espère que cela aide aussi!

0
dmarges