Il processo mysql non può essere interrotto

Question

Ho recentemente installato 5.5.28-29.2 Percona Server (GPL), Release 29.2 in un desktop OS Ubuntu 12.04. Ho cercato di arrestare il server utilizzando diversi metodi:

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

Tutti questi metodi di fermare il processo, tuttavia si avvia automaticamente dopo muore. syslog Ho controllato (/ var/log/syslog /) e mi mostra sempre la prossima traccia:

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 

Non si conosce il motivo per cui il processo si riavvia automaticamente? Grazie in anticipo !!

Answer 1

Stavo avendo lo stesso identico problema. L'esecuzione del comando kill ucciderebbe il processo, ma nel mio caso continuerà a comparire in un altro ID di processo.

L'unico modo ho potuto capire come fermarlo per sempre stata questa:

sudo stop mysql 

Speranza che aiuta.

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

Answer 2

Sto andando a indovinare qui, ma mysqld potrebbe essere avviato tramite lo script di init mysql_safe, che riavvierà il server.

Answer 3

Vuoi uccidere tutte le istanze MySQL? Prova come root:

pkill mysqld; 

Answer 4

Utilizzando sudo service mysql stop ha lavorato per me.

Answer 5

Questo potrebbe non essere applicabile a questo particolare problema ma qui va comunque. Ho controllato il log degli errori ("/var/log/mysql/error.log") e ho visto che "explicit_defaults_for_timestamp = TRUE" stava causando un errore ("Variabile sconosciuta"). Quindi l'ho rimosso da my.cnf ("/etc/mysql/my.cnf"), e ho lanciato "sudo start mysql" e il backup era attivo. Spero che questo aiuti pure!

Answer 6

Per coloro che guardavano a questi anni dopo il fatto, ho avuto un problema simile e ho appena risolto.

Sembra che ci fosse un secondo script di init chiamato orig_mysql.conf che esisteva nella directory/etc/init insieme al file mysql.conf. Ciò ha causato l'avvio di due istanze da parte di upstart e apparentemente si è confuso quando ne è stato terminato uno. Come tale ha avuto luogo un respawn continuo.

La mia soluzione:

1. mysql arresto tramite upstart, se possibile: service mysql stop
2. rimuovere uno dei file CONF (ho tolto /etc/init/orig_mysql.conf). Quindi riavviare init utilizzando: telinit u
3. Elimina manualmente eventuali processi mysqld rimanenti.

Una volta che confermare il possesso di nessun processo mysqld in esecuzione e che essi non sono più respawning, riavviare mysql con service mysql start.

Spero che questo aiuti qualcuno. Mi ci sono voluti due anni per risolvere questo.

Answer 7

Dovresti semplicemente rimuovere mysql.sock. In questo modo, eseguendo nuovamente il servizio mysqld, lo ricreerà. Se non è il caso, è sufficiente riavviare il server dopo aver rimosso mysql.sock

Answer 8

Sto usando Homebrew su Mac OS. brew services stop mysql ha fatto non lavoro per me, ma sudo brew services stop mysql ha fatto.