Fehlschlag mit MariaDB
Hallo. Vorhin habe ich mein erstes "zypper dup" gemacht, noch in meiner virtuellen Maschine. Es wurde (nach etwa zwei Wochen) eine MENGE erneuert. Aber die Erneuerung von MariaDB ist fehlgeschlagen. Die zypper-Meldungen habe ich leider nicht mitgeschnitten. Wenn ich jetzt "zypper dup" erneut mache, bekomme ich: /home/vw % zypper dup (...) Distributions-Aktualisierungen werden verarbeitet... Keine auszuführenden Aktionen. Doch MariaDB läuft nicht. Wenn ich es versuche mit "systemctl start mariadb" zu starten, bekomme ich einen Fehler: Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xeu mariadb.service" for details. Hier ist die Ausgabe von "systemctl status mariadb": https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost: Ich habe es neu installiert und neu gebootet, aber das Problem bleibt. Was ist los? Ist das so ein Problem, das bei einer Rolling-Release- Distribution mal auftritt und in der nächsten Aktualisierung behoben wird? Ich bin etwas enttäuscht. :-( Viele Grüße, Volker
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost:
Da ist was schief gelaufen. Die Adresse ist: https://paste.opensuse.org/pastes/92b245d04cdc Volker
Hallo Am Mittwoch, dem 11.12.2024 um 14:04 +0100 schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost:
Da ist was schief gelaufen. Die Adresse ist:
https://paste.opensuse.org/pastes/92b245d04cdc
was zeigt mariadb an wenn du es per Hand startes ? mysqld (eventuell mit Pfad zu config)
Gruß Torsten
Am Mittwoch, dem 11.12.2024 um 14:28 +0100 schrieb Torsten Rosenberger:
Hallo
Am Mittwoch, dem 11.12.2024 um 14:04 +0100 schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost:
Da ist was schief gelaufen. Die Adresse ist:
https://paste.opensuse.org/pastes/92b245d04cdc
was zeigt mariadb an wenn du es per Hand startes ? mysqld (eventuell mit Pfad zu config)
root@localhost:/home/vw % mysqld mysqld: Deprecated program name. It will be removed in a future release, use '/usr/sbin/mariadbd' instead mysqld: Please consult the Knowledge Base to find out how to run mysqld as root! 2024-12-11 16:00:49 0 [ERROR] Aborting Und in der Manseite steht: Default options are read from the following files in the given order: /etc/my.cnf ~/.my.cnf Volker
Am Mittwoch, dem 11.12.2024 um 16:04 +0100 schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:28 +0100 schrieb Torsten Rosenberger:
Hallo
Am Mittwoch, dem 11.12.2024 um 14:04 +0100 schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost:
Da ist was schief gelaufen. Die Adresse ist:
https://paste.opensuse.org/pastes/92b245d04cdc
was zeigt mariadb an wenn du es per Hand startes ? mysqld (eventuell mit Pfad zu config)
root@localhost:/home/vw % mysqld mysqld: Deprecated program name. It will be removed in a future release, use '/usr/sbin/mariadbd' instead mysqld: Please consult the Knowledge Base to find out how to run mysqld as root! 2024-12-11 16:00:49 0 [ERROR] Aborting
Und in der Manseite steht:
Default options are read from the following files in the given order: /etc/my.cnf ~/.my.cnf
/var/log/mysql/
In /var/log/mysql/mysqld.log steht nichts [ERROR]
Am Mittwoch, 11. Dezember 2024, 14:04:08 Mitteleuropäische Normalzeit schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost: Da ist was schief gelaufen. Die Adresse ist:
Wenn der systemd nix weiß, guck doch mal ins mysql.log. Ein weiterer Störenfried könnte ein liegen gebliebenes pid-File sein. Helga -- Technik - openSUSE Tumbleweed Politik - https://bge-community.de
Am Mittwoch, dem 11.12.2024 um 15:51 +0100 schrieb Helga Fischer:
Am Mittwoch, 11. Dezember 2024, 14:04:08 Mitteleuropäische Normalzeit schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost: Da ist was schief gelaufen. Die Adresse ist:
Wenn der systemd nix weiß, guck doch mal ins mysql.log.
Da ist bloß das Hochfahren heute Mittag und danach ein Runterfahren drin. Das müßte anläßlich des "zypper dup" geschehen sein. Danach nichts mehr. Ich habe die Einträge von heute mal hier abgelegt: https://paste.opensuse.org/pastes/5e9004b5103d
Ein weiterer Störenfried könnte ein liegen gebliebenes pid-File sein.
Habe in / abwärts nach "*.pid", "*.lock" und "lock" gesucht und nichts Verdächtiges gefunden... Tschüß Volker
Am Mittwoch, 11. Dezember 2024, 16:22:10 Mitteleuropäische Normalzeit schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 15:51 +0100 schrieb Helga Fischer:
Am Mittwoch, 11. Dezember 2024, 14:04:08 Mitteleuropäische
Normalzeit schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/ 92b245d04cdcroot@localhost: Da ist was schief gelaufen. Die Adresse ist:
Wenn der systemd nix weiß, guck doch mal ins mysql.log.
Da ist bloß das Hochfahren heute Mittag und danach ein Runterfahren drin. Das müßte anläßlich des "zypper dup" geschehen sein. Danach nichts mehr.
Mit einer zeitlichen Lücke von 9 Minuten. OK. Und danach nix mehr in den Logs? Also kein Hinweis darauf, warum die mysql nicht mehr hochfährt? journaltctl -f anwerfen und dann die mysql. Irgendwo muss es doch einen Hinweis geben.
Ich habe die Einträge von heute mal hier abgelegt:
Außer der Lücke kann ich da nichts sehen.
Ein weiterer Störenfried könnte ein liegen gebliebenes pid-File sein.
Habe in / abwärts nach "*.pid", "*.lock" und "lock" gesucht und nichts Verdächtiges gefunden...
Schade, einen Versuch war's wert. Dann fällt mir nur noch einen strace auf den Startvorgang der mysql zu setzen. Helga -- Technik - openSUSE Tumbleweed Politik - https://bge-community.de
Am Mittwoch, 11. Dezember 2024, 14:04:08 CET schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 14:00 +0100 schrieb Volker Wysk:
https://paste.opensuse.org/pastes/92b245d04cdcroot@localhost: Da ist was schief gelaufen. Die Adresse ist:
Evtl.: 2024-12-11 13:34:00 0 [ERROR] feedback plugin: failed to retrieve the MAC address https://mariadb.com/kb/en/feedback-plugin/ Gruß Eric
Am 11.12.24 um 2:00 PM schrieb Volker Wysk:
Vorhin habe ich mein erstes "zypper dup" gemacht, noch in meiner virtuellen Maschine. Es wurde (nach etwa zwei Wochen) eine MENGE erneuert. Aber die Erneuerung von MariaDB ist fehlgeschlagen.
Die zypper-Meldungen habe ich leider nicht mitgeschnitten.
Du findest die vermutlich in /var/log/zypper.log
Doch MariaDB läuft nicht. Wenn ich es versuche mit "systemctl start mariadb" zu starten, bekomme ich einen Fehler:[...]
Löst sich das Problem, wenn Du den alten Snapshot wieder startest? Wenn ja: Bugreport. Wenn nein: Config prüfen.
Was ist los? Ist das so ein Problem, das bei einer Rolling-Release- Distribution mal auftritt und in der nächsten Aktualisierung behoben wird?
Ich bin etwas enttäuscht. :-(
Das tut mir leid. Wie kann man Dich trösten? Viele Grüßé Ulf
Am Mittwoch, dem 11.12.2024 um 14:27 +0100 schrieb Ulf Volmer:
Am 11.12.24 um 2:00 PM schrieb Volker Wysk:
Vorhin habe ich mein erstes "zypper dup" gemacht, noch in meiner virtuellen Maschine. Es wurde (nach etwa zwei Wochen) eine MENGE erneuert. Aber die Erneuerung von MariaDB ist fehlgeschlagen.
Die zypper-Meldungen habe ich leider nicht mitgeschnitten.
Du findest die vermutlich in /var/log/zypper.log
Doch MariaDB läuft nicht. Wenn ich es versuche mit "systemctl start mariadb" zu starten, bekomme ich einen Fehler:[...]
Löst sich das Problem, wenn Du den alten Snapshot wieder startest? Wenn ja: Bugreport. Wenn nein: Config prüfen.
Ich hab mal "snapper undochange 91..0" gemacht. Snapshop 91 ist der pre- Snapshot meines ersten "zypper dup". Doch das Problem besteht immernoch. MariaDB ist tot und die Meldung von "systemctl config mariadb" ist die gleiche wie vorher. Ich habe diese Meldung von "snapper undochange 91..0" bekommen: angelegt:278 geändert:1866 gelöscht:557 Welche "Config" soll ich prüfen?
Was ist los? Ist das so ein Problem, das bei einer Rolling-Release- Distribution mal auftritt und in der nächsten Aktualisierung behoben wird?
Ich bin etwas enttäuscht. :-(
Das tut mir leid. Wie kann man Dich trösten?
Am besten streicheln. Tschüß, Volker
Am Mittwoch, 11. Dezember 2024, 15:52:27 Mitteleuropäische Normalzeit schrieb Volker Wysk:
Welche "Config" soll ich prüfen?
systemctl spuckt bei mir: /usr/sbin/mysqld --defaults-file=/etc/my.cnf --user=mysql --socket=/ run/mysql/mysql.sock aus. Die my.cnf könntest Du angucken. Vielleicht hast Du aber noch ein mysql.sock rumliegen, das stört. (Obwohl ich der Meinung bin, dass man das in den Fehlermeldungen sieht).
Was ist los? Ist das so ein Problem, das bei einer Rolling-Release- Distribution mal auftritt und in der nächsten Aktualisierung behoben wird?
Ich habe auch eine mysql (nicht produktiv) hier laufen und mache die Updates auch immer, ohne sie herunter zu fahren, was man eigentlich tun sollte. Bisher hatte ich nie Probleme damit. Insofern: Nie wieder was anderes als Rolling Release. Schau bitte in dein Log. Vielleicht kommt dann Licht in die Sache. Helga -- Technik - openSUSE Tumbleweed Politik - https://bge-community.de
Am Mittwoch, dem 11.12.2024 um 16:11 +0100 schrieb Helga Fischer:
Am Mittwoch, 11. Dezember 2024, 15:52:27 Mitteleuropäische Normalzeit schrieb Volker Wysk:
Welche "Config" soll ich prüfen?
systemctl spuckt bei mir:
/usr/sbin/mysqld --defaults-file=/etc/my.cnf --user=mysql --socket=/ run/mysql/mysql.sock
Dort in /run/mysql ist bei mir eine kleine Textdatei namens "protecteddir.", die den Pfad zu einem Verzeichnis /var/tmp/mysql-protected.* enthält (statt dem "*" eine zufälliger String). Ich habe wieder "systemctl start mysql" gemacht und dort in dem Verzeichnis die Logdatei von diesem Startversuch gefunden. Es steht drin, daß MariaDB hochgefahen wurde: (...) 2024-12-11 16:34:56 0 [Note] /usr/sbin/mysqld: ready for connections. Version: '11.6.1-MariaDB' socket: '/var/tmp/mysql- protected.4w0s5E/mysql.sock' port: 0 MariaDB package Nach einer Minute kommt ein "normal shutdown", der auch normal aussieht: /usr/sbin/mysqld (initiated by: unknown): Normal shutdown (...) Irgendwas sorgt dafür daß MariaDB gleich wieder heruntergefahren wird...
aus. Die my.cnf könntest Du angucken.
Ja, hab ich gemacht UND DIE URSACHE GEFUNDEN. Ich hatte in my.cnf das eingetragen (in allen drei Abschnitten): "max_allowed_packet=500M". Das brauche ich für Tiki. Jetzt habe ich diese Änderungen rückgängig gemacht und MariaDB läßt sich starten. MariaDB hatte zuvor mit dem "may_allowed_packet=500M" funktioniert. Die neue Version, die das "zypper dup" eingespielt hat, muß sich daran stören - ohne eine Meldung in den Logs. Vielen Dank an alle, die geholfen haben. Tschüß, Volker
Am 11.12.24 um 17:03 schrieb Volker Wysk:
Ich hatte in my.cnf das eingetragen (in allen drei Abschnitten): "max_allowed_packet=500M". Das brauche ich für Tiki. Jetzt habe ich diese Änderungen rückgängig gemacht und MariaDB läßt sich starten.
Mystisch. Kann ich hier so nicht reproduzieren. Viele Grüße Ulf
Am Mittwoch, dem 11.12.2024 um 17:17 +0100 schrieb Ulf Volmer:
Am 11.12.24 um 17:03 schrieb Volker Wysk:
Ich hatte in my.cnf das eingetragen (in allen drei Abschnitten): "max_allowed_packet=500M". Das brauche ich für Tiki. Jetzt habe ich diese Änderungen rückgängig gemacht und MariaDB läßt sich starten.
Mystisch. Kann ich hier so nicht reproduzieren.
Ich muß mich morgen nochmal damit auseinandersetzen. Ich habe Schnappschüsse noch nicht gut genug verstanden. Tschüß Volker
Am 11.12.24 um 5:29 PM schrieb Volker Wysk:
Am Mittwoch, dem 11.12.2024 um 17:17 +0100 schrieb Ulf Volmer:
Am 11.12.24 um 17:03 schrieb Volker Wysk:
Ich hatte in my.cnf das eingetragen (in allen drei Abschnitten): "max_allowed_packet=500M". Das brauche ich für Tiki. Jetzt habe ich diese Änderungen rückgängig gemacht und MariaDB läßt sich starten.
Mystisch. Kann ich hier so nicht reproduzieren.
Ich muß mich morgen nochmal damit auseinandersetzen. Ich habe Schnappschüsse noch nicht gut genug verstanden.
OK. Ich wollte nur darauf niweisen, dass ich hier auf einem aktuellen TW deine Einträge in der my.cnf gemacht habe und der mariadb brav startet. Viele Grüße ulf
Am 11.12.24 um 3:52 PM schrieb Volker Wysk:
Ich hab mal "snapper undochange 91..0" gemacht. Snapshop 91 ist der pre- Snapshot meines ersten "zypper dup". Doch das Problem besteht immernoch. MariaDB ist tot und die Meldung von "systemctl config mariadb" ist die gleiche wie vorher.
Ich bin mir ehrlich nicht sicher, was Dein Kommando tut. Ich hätte ein 'snapper rollback 91' gemacht, das erstellt eine rw Snapshot aus dem ro 91er, in den Du dann reinbooten kannst.
Welche "Config" soll ich prüfen?
Na, die von mariadb. Eine Kombination von /etc/my.cnf, /etc/my.cnf.d/* und ggf. dotfiles im Homedir des mysql Users. **Wenn** der Rollback das Problem nicht löst, muss es ja quasi ein Layer 8 Problem sein, Viele Grüße Ulf
Am Mittwoch, dem 11.12.2024 um 16:19 +0100 schrieb Ulf Volmer:
Am 11.12.24 um 3:52 PM schrieb Volker Wysk:
Ich hab mal "snapper undochange 91..0" gemacht. Snapshop 91 ist der pre- Snapshot meines ersten "zypper dup". Doch das Problem besteht immernoch. MariaDB ist tot und die Meldung von "systemctl config mariadb" ist die gleiche wie vorher.
Ich bin mir ehrlich nicht sicher, was Dein Kommando tut. Ich hätte ein 'snapper rollback 91' gemacht, das erstellt eine rw Snapshot aus dem ro 91er, in den Du dann reinbooten kannst.
Welche "Config" soll ich prüfen?
Na, die von mariadb. Eine Kombination von /etc/my.cnf, /etc/my.cnf.d/* und ggf. dotfiles im Homedir des mysql Users.
**Wenn** der Rollback das Problem nicht löst, muss es ja quasi ein Layer 8 Problem sein,
Es war eine Inkompatibilität der neuen MariaDB-Version mit der alten, bezüglich der my.cnf. Siehe meine Antwort an Helga. Tschüß, Volker
participants (5)
-
Eric Schirra -
Helga Fischer -
Torsten Rosenberger -
Ulf Volmer -
Volker Wysk