Systemd MySQL wird nicht aufhören


17

Nach dem Upgrade auf 15.04 hatte ich viel Spaß beim Kennenlernen von systemd. Ich glaube, ich habe alles am Laufen, außer ich kann mysql.service nicht stoppen. Der Befehl systemctl bleibt einfach hängen und mysql läuft einfach weiter. Hat jemand anderes dies erlebt oder weiß er vielleicht, was los ist?


2
Standardmäßig wird der Dienst nach 3 Minuten mit SIGKILL blockiert (wenn der Dienst nicht normal beendet wird). Wahrscheinlich müssen Sie die Konfigurationsdateien von mysql.service lesen.
Velkan

2
Welche MySQL-Version verwenden Sie? Hast du das native mysql.serviceSkript verwendet oder dein eigenes gerollt?
Jos

Es ist 5.6, was aus dem offiziellen Vivid Repo hervorgeht. Ich verwende das Skript, das mit diesem Paket geliefert wird.
Craig Dunford

Wir hatten das gleiche Problem und haben einen Fehlerbericht eingereicht .
EOLE-Team

Antworten:


25

Ich hatte das gleiche Problem (Upgrade auf 15.04, mit offiziellen Dateien und Config).

Ich musste die folgenden Änderungen vornehmen, um den mysqlDämon manuell mit sytemctlund automatisch beim Neustart / Herunterfahren des Systems stoppen zu können :

  1. Stellen /etc/mysql/debian.cnflesbar für den mysqlBenutzer mit

    sudo chgrp mysql /etc/mysql/debian.cnf; sudo chmod 640 /etc/mysql/debian.cnf
    
  2. Geben Sie eine leicht geänderte mysql.serviceDatei an:

    sudo cp /lib/systemd/system/mysql.service /etc/systemd/system/
    sudo chmod 755 /etc/systemd/system/mysql.service
    
  3. Geben Sie einen expliziten Stoppbefehl ein, indem Sie die kopierte Datei in einem Editor öffnen:

    sudo nano /etc/systemd/system/mysql.service
    

    und die folgende Zeile unter dem [Service]Abschnitt hinzufügen :

    ExecStop=/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf shutdown
    

    Verwenden Sie in Nano Strg + O zum Speichern (Linux-Modus!) Und Strg + X zum Beenden.

  4. Machen Sie die neue Servicedatei dem System bekannt:

    sudo systemctl daemon-reload
    

Mein Kubuntu friert beim Herunterfahren mit ein. Für MySQL Community Server wird ein Stop-Job ausgeführt [1min 16s / 10min] . Diese Antwort hat das Problem gelöst. Vielen Dank.
lolmaus - Andrey Mikhaylov

Mein 14.10 -> 15.04-Upgrade (das MySQL 5.5 auf 5.6 verschoben hat) verursachte dasselbe Problem. Obwohl MySQL 'funktioniert', wird es nicht richtig heruntergefahren, so dass Ubuntu beim Herunterfahren hängen bleibt. Es sieht so aus, als ob das Problem mit der Änderung der MySQL-Version in Verbindung mit dem Ersetzen von Upstart durch systemd zusammenhängt. Dieser Link behandelt einige Aktualisierungen der MySQL-Konfiguration, um Warnungen usw. auszusortieren. Beim Starten von MySQL wird auch immer über ein falsches Herunterfahren geklagt, da systemd den Vorgang nur nach 10 Minuten abbricht, wenn Sie so lange warten können.
Mike

1
Dasselbe Problem in Debian Jessie / Testen mit MySQL 5.6 - dank Ihnen
behoben

Ich hasse es, das tun zu müssen, aber ich bin so froh, dass es funktioniert, danke Udo!
Gabriel Baker

Es hat das Problem auf LinuxMint 18 nicht gelöst.
sivaprasadreddy.k

1

Ich hatte das gleiche Problem mit Ubuntu 15.10 Desktop und fand einen Weg, es zu beheben:

Der Parameter log_error in /etc/mysql/mysql.conf.d/mysqld.cnf wurde auskommentiert. Nachdem der Parameter aus dem Kommentar entfernt wurde, fährt systemd mysqld ohne Probleme herunter.


Ich hatte das gleiche Problem auf Ubuntu LTS 16.04. Nur das Deaktivieren des error.log hat funktioniert. Jetzt schreibt mysqld über die --log-syslogOption ins Journal. Vielleicht ein Grund: Das Root-Dateisystem war btrfs.
Ingopingo

1

Ihr Problem ist thread_pool_size. Wenn es viel höher als die Anzahl der Kerne / Threads ist, können Sie nicht ordnungsgemäß herunterfahren, es sei denn, Sie verwenden den Befehl mysqladmin shutdown.

ZB: Sie haben 2 Kerne CPU mit 4 Threads. Wenn Sie 1-4 einstellen, funktioniert es einwandfrei. Wenn Sie den Wert auf 16 setzen, wie in vielen "Hochleistungs" -Blogs empfohlen, wird der Wert gestrichen.


1

Ich hatte ein ähnliches Problem mit mysql / mariadb, das nicht beendet werden konnte, wenn es von systemd angewiesen wurde , entweder beim Herunterfahren oder manuell mit sudo service mysql stop.

In meinem Fall boote ich Ubuntu / Windows doppelt im UEFI-Modus und diese Betriebssysteme interpretieren unterschiedliche Hardwarezeiten, sodass beide Betriebssysteme beim Start mit Internet-Zeitservern synchronisiert werden.

MySQL (und Mariadb) konnten nicht gestoppt werden, wenn sich die Hardware-Zeit während der Ausführung geändert hat.

Sie müssen den Start von MySQL bis nach der Zeitsynchronisation verschieben. Im Idealfall würde dies durch Einfügen einer temporären Abhängigkeit von mysql mit erfolgen, After: time-syncaber das hat bei mir nicht funktioniert.

Die Lösung, die bei mir funktioniert hat (Sie können mysql mit mariadb ersetzen, um den gleichen Effekt zu erzielen):

  1. Deaktivieren Sie MySQL mit sudo systemctl disabled mysql.service

  2. Erstellen Sie ein Skript (stellen Sie sicher, dass es ausführbar ist), das mysql nach einiger Zeit /usr/bin/delay_mysqlmit folgendem Inhalt startet :

    #!/bin/sh
    sleep 30s
    /etc/init.d/mysql start
    
  3. Erstellen Sie einen systemd-Dienst, um Ihr neues Skript /etc/systemd/system/delay_mysql.service mit Inhalten auszuführen :

    [Unit]
    Description=Delay start of MySQL / MariaDB
    
    [Service]
    Type=oneshot
    ExecStart=/usr/bin/delay_mysql
    
    [Install]
    WantedBy=multi-user.target  
    
  4. Registrieren Sie Ihren neuen Dienst bei sudo systemctl enable delay_mysql.service

Dadurch wird Ihr Skript auf Mehrbenutzerebenen ausgeführt, die unter Ubuntu 3,4,5 betragen.


Es hat mein Problem gelöst. Es ist jedoch sehr wichtig zu beachten, dass Sie delay_mysql.service vor der Neuinstallation von MySql deaktivieren sollten, da sonst ein Fehler auftritt.
SiGe

0

Gerade beim Kopieren muss mysql.serviceman ein chmodAfter machen.

cp /lib/systemd/system/mysql.service /etc/systemd/system/
chmod 755 /etc/systemd/system/mysql.service

0

In meinem Fall war es ein Passwortkonflikt für den Wartungsbenutzer debian-sys-maintzwischen einem in /etc/mysql/debian.cnfund einem in der MySQL-Datenbank.

Dieser Benutzer wird für das Herunterfahren von MySQL und andere Funktionen verwendet. Nach dem MySQL-Update kann es vorkommen, dass zwischen Datei und Datenbank ein Pass-Konflikt besteht. Dies kann auch passieren, wenn Sie Ihre Datenbank von einem MySQL-System auf ein anderes verschieben. Wenn Sie alle Datenbanken und Benutzer von einem anderen MySQL-Computer importieren möchten, müssen Sie Ihr Wartungsbenutzer- debian-sys-maintKennwort ( ) erneut synchronisieren .

Sie müssen Folgendes tun: Überprüfen Sie Ihr aktuelles Passwort in der Ubuntu / Debian-Datei:

sudo cat /etc/mysql/debian.cnf

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = n4aSHUP04s1J32X5
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
user     = debian-sys-maint
password = n4aSHUP04s1J32X5
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Hier können Sie Ihr Passwort sehen, das das System verwenden wird: password = n4aSHUP04s1J32X5

Der nächste Schritt besteht darin, MySQL auf dasselbe Passwort zu aktualisieren: Melden Sie sich bei MySQL an:

~$ mysql -u root -p

Geben Sie Ihr Passwort ein, um auf MySQL zuzugreifen

mysql> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'n4aSHUP04s1J32X5';**

Danach gibt es keine Probleme mehr mit dem Herunterfahren, keine 10 Minuten Wartezeit, keine Probleme mit der Installation von Apps, die dieses Wartungskonto verwenden, wie z. B. phpmyadmin.

UPDATE: Leider hat dies das Problem nicht gelöst. Es wurde zufällig ausgewählt - manchmal kann ich den Dienst ohne Probleme beenden, wenn er beim Beenden des Dienstes ein weiteres Mal einfriert.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.