Fehler bei Update auf 4-0.345 /etc/mysql/my.cnf is a symlink but does not point to /usr/local/pd-admin2/etc/my.cnf

  • - Welche Version von pd-admin wird eingesetzt?

    v4.62


    - Welche Version der Serverumgebung wird eingesetzt?

    4-0.342


    - Welche Fehlermeldung erhalten Sie?


    ~/seu3 # ./se-update.sh

    FREESPACE = </root/seu3/freespace64>

    READLINK = </root/seu3/readlink64>

    MYCP = </root/seu3/cp64>

    /etc/mysql/my.cnf is a symlink but does not point to /usr/local/pd-admin2/etc/my.cnf

    exiting ...


    Die Fehlermeldung tritt beim Versuch (SE) 0.345 mittels se-update.sh zu installieren auf.


    Es wurden keine Änderungen an der my.conf durchgeführt (Verschieben etc.).

  • Hmm ok danke.


    Habe nochmals nachgeschaut und der symlink wird (hier unter Debian) von (update-)alternatives verwaltet - und wurde im Zuge einer netdata Installation automatisch dazu installiert.


    Entfernen des Symlinks kann daher Auswirkungen auf andere Komponenten haben.


    Mir stellt sich auch die Frage warum an dieser Stelle vom Update Skript überhaupt in /etc/my.cnf nachgeschaut wird wenn das eigentliche Skript ja in /usr/local/pd-admin2/etc/my.cnf liegt?


    Danke

  • Mir stellt sich auch die Frage warum an dieser Stelle vom Update Skript überhaupt in /etc/my.cnf nachgeschaut wird wenn das eigentliche Skript ja in /usr/local/pd-admin2/etc/my.cnf liegt?

    Das hat durchaus seinen Grund. Das Problem ist, dass der mysqld einer cnf Datei in /etc stets den Vorrang gibt wenn eine existiert und dann diese einliest. Früher, als es diesen Check noch nicht gab, ist der mysqld der Standardumgebung dann auf einmal mit den Settings aus der Distri-my.cnf gestartet und daher kam natürlich Quatsch raus. Aufgefallen ist das dann meist nach einem Update oder Neustart und dann wurde es schnell mal hektisch.

    Daher wurde AFAIR dann mal dieser Check eingebaut. Wenn auf dem Server keine andere mysql Instanz läuft (was im Normalfall mehr als unwahrscheinlich ist) kann die Datei bzw. der Symlink unter /etc problemlos gelöscht werden meiner Erfahrung nach.

  • Ich habe bei mir (CentOS) ebenfalls netdata installiert. Dort wird/wurde der Symlink nicht angelegt. netdata selber ist auch nicht auf den MySQL Dienst angewiesen.


    Wie gesagt, man kann den Symlink auch erst einmal nur umbenennen und schauen, ob es Probleme gibt.


    Andere Frage: worauf zeigt denn der Symlink, wenn nicht auf die my.cnf der Serverumgebung?

  • Ok, euch beiden erstmals vielen Dank für die Antworten.

    Zitat

    Andere Frage: worauf zeigt denn der Symlink, wenn nicht auf die my.cnf der Serverumgebung?

    /etc/alternatives/my.cnf -> /etc/mysql/my.cnf.fallback


    Und die /etc/mysql/my.cnf.fallback ist eine Vanilla my.cnf.


    Zitat

    Ich habe bei mir (CentOS) ebenfalls netdata installiert. Dort wird/wurde der Symlink nicht angelegt. netdata selber ist auch nicht auf den MySQL Dienst angewiesen.

    Es kam durch das mysql Plugin für netdata dazu, nicht durch die netdata Installation direkt.


    Zitat

    Das Problem ist, dass der mysqld einer cnf Datei in /etc stets den Vorrang gibt wenn eine existiert und dann diese einliest. Früher, als es diesen Check noch nicht gab, ist der mysqld der Standardumgebung dann auf einmal mit den Settings aus der Distri-my.cnf gestartet und daher kam natürlich Quatsch raus.

    Ok, ja das macht Sinn. Auf einem Testsystem war in diesem Szenario parallel nach ein MariaDB installiert (hat problemlos funktioniert).


    Ich werde den Symlink entfernen.


    Besten Dank nochmals für die Erklärung.

  • mkpd15

    Hat das Label [erledigt] hinzugefügt