[epgd] "SQL-Error in 'select epglv('123', '123')' - FUNCTION epg2vdr.epglv does not exist" ist aber vorhanden...

  • Hab folgendes im Logfile von meinem EPGD Debian Testing Server:

    Code
    Nov 18 11:43:43 uti-srv02 epgd: Calling mysql_init(838073)
    Nov 18 11:43:43 uti-srv02 epgd: State now 'init'
    Nov 18 11:43:43 uti-srv02 epgd: SQL-Error in 'select epglv('123', '123')' - FUNCTION epg2vdr.epglv does not exist (1305) 
    Nov 18 11:43:43 uti-srv02 epgd: SQL-Error in 'select epglvr('123', '123')' - FUNCTION epg2vdr.epglvr does not exist (1305) 
    Nov 18 11:43:43 uti-srv02 epgd: Error: Missing functions epglv/epglvr, please install first!
    Nov 18 11:43:43 uti-srv02 epgd: Closing mysql connection and calling mysql_thread_end(838073)


    Installiert sind folgende Pakete:


    Die Pakete von EPGD sind mit dem "debian" File aus yaVDR erstellt ohne Python3 Patch, extra zum Test und zum verifizieren gegenüber meinem "debian" Ordner der auf einem anderen System genauso funktioniert nur auf diesen einen Server eben nicht.


    Die Funktion ist auch in der Datenbank:

    Code
    Database changed
    MariaDB [epg2vdr]> SELECT * FROM mysql.func;
    +--------+-----+---------------+----------+
    | name   | ret | dl            | type     |
    +--------+-----+---------------+----------+
    | epglv  |   2 | mysqlepglv.so | function |
    | epglvr |   2 | mysqlepglv.so | function |
    +--------+-----+---------------+----------+
    2 rows in set (0.005 sec)


    Plugin im System:

    Code
    locate mysqlepglv.so
    /usr/lib/x86_64-linux-gnu/mariadb19/plugin/mysqlepglv.so


    Den Pfad in der my.cnf zu setzen half auch nicht...


    Was kann das Verhalten noch verursachen?

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Durch Zufall wurde heute was ins Log geschrieben, was so zuvor noch nicht "sichtbar" war, hier die vielfache Ausgabe im error.log:

    Code
    2020-11-25  9:35:19 0 [Note] Using unique option prefix 'myisam-recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead.
    2020-11-25  9:35:19 0 [Note] InnoDB: Using Linux native AIO
    2020-11-25  9:35:19 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2020-11-25  9:35:19 0 [Note] InnoDB: Uses event mutexes
    2020-11-25  9:35:19 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
    2020-11-25  9:35:19 0 [Note] InnoDB: Number of pools: 1

    und dann das, per Zufall eher:

    Code
    2020-11-25  9:42:25 0 [Note] Using unique option prefix 'myisam-recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead.
    2020-11-25  9:42:25 0 [ERROR] mysqld: Plugin 'innodb' already installed
    2020-11-25  9:42:25 0 [ERROR] mysqld: Can't open shared library '/usr/lib/mysql/plugin/ha_federated.so' (errno: 0, cannot open shared object file: No such file or directory)
    2020-11-25  9:42:25 0 [ERROR] mysqld: Can't open shared library '/usr/lib/mysql/plugin/ha_blackhole.so' (errno: 0, cannot open shared object file: No such file or directory)
    2020-11-25  9:42:25 0 [ERROR] mysqld: Can't open shared library '/usr/lib/mysql/plugin/ha_archive.so' (errno: 0, cannot open shared object file: No such file or directory)
    2020-11-25  9:42:25 0 [Note] InnoDB: Using Linux native AIO
    2020-11-25  9:42:25 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2020-11-25  9:42:25 0 [Note] InnoDB: Uses event mutexes
    2020-11-25  9:42:25 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
    2020-11-25  9:42:25 0 [Note] InnoDB: Number of pools: 1

    keine Ahnung warum mysqld das nicht immer geschrieben hat.


    Dann hab ich mal gesucht:

    Code
    mysql -u root -p -e "SELECT @@plugin_dir;"
    Enter password: 
    +------------------------+
    | @@plugin_dir           |
    +------------------------+
    | /usr/lib/mysql/plugin/ |
    +------------------------+

    komisch, bin davon ausgegangen da mariadb verwendet wird und KEIN Pfad gesetzt ist in der Konfiguration dass das Verzeichnis

    /usr/lib/x86_64-linux-gnu/mariadb19/plugin/

    dafür verwendet wird.


    Zum Test hab ich mal die Plugin an den genannten Platz kopiert und siehe da, EPGD läuft wieder.


    Nur warum ist bei Debian der Plugin-Pfad vom mariadb nicht der wo als Default vorhanden ist und wo auch die Plugins liegen und was macht man um das System für weitere Updates ausfallsicher zu bekommen?

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Also bei mir (focal, yavdr-ansible) existiert das /var/lib/mysql/plugin/ - Verzeichnis nicht.

    In der DB ist auch brav das

    Code
    +---------------------------------------------+
    | @@plugin_dir                                |
    +---------------------------------------------+
    | /usr/lib/x86_64-linux-gnu/mariadb19/plugin/ |
    +---------------------------------------------+

    eingetragen, und das mysqlepglv.so existiert dortselbst :)

    Kann wohl nur ein Überbleibsel der alten mysql-Konfig sein.

  • Bringt mir nichts, was bei ubuntu@focal ist.

    Geht er darum ob es was bringt den Pfad umzuändern oder anderweitig was zu ändern damit es weiterhin funktioniert.

    Trotzdem danke für die Info.

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Bin nun per Zufall darauf gestoßen: epgd /mariadb mysqlepglv.so im falschen Plugin Verzeichniss


    Das Paket libmariadb-dev-compathatte ich installiert und es zeigt auch auf:

    Code
    mysql_config --plugindir
    /usr/lib/x86_64-linux-gnu/mariadb19/plugin


    die Datenbank jedoch auf das oben genannte. Kann man diesen Wert ändern / anpassen in der Datenbank?

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Hallo,


    Debian Buster (als Testing) verwendete schon diesen Pfad (damals noch mariadb18).

    Ich habe das einfach in "vdr-epg-daemon/debian/mysql-plugin-epglv.install" angepaßt:

    Code
    #!/usr/bin/dh-exec
    #usr/lib/mysql/plugin/mysqlepglv.so => usr/share/vdr-epg-daemon/mysql/plugin/mysqlepglv.so
    #usr/lib/x86_64-linux-gnu/mariadb18/plugin/mysqlepglv.so => usr/share/vdr-epg-daemon/mysql/plugin/mysqlepglv.so
    usr/lib/arm-linux-gnueabihf/mariadb19/plugin/mysqlepglv.so => usr/share/vdr-epg-daemon/mysql/plugin/mysqlepglv.so


    HTH,

    Stefan

  • Das funktioniert ja wie Eingangs schon beschrieben, die Installation, darum geht es nicht ;)


    Code
    usr/lib/*/mariadb*/plugin/mysqlepglv.so
    debian/mariadb-plugin-epglv.sql usr/lib/epgd/


    Es geht darum dass der Pfad nicht gesetzt ist in der Konfiguration aber dennoch der "Falsche" vorhanden ist. Die Frage ist eher, wo kommt der her und wie kann der angepasst werden da mariadb ja noch den Zahlenwert im Pfad hat, wenn sich der ändert durch ein Update passt es wieder nicht...

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Lösch doch mal die UDFs und füge sie dann wieder neu hinzu. Wenn du die in die Datenbank importiert hattest, als noch ein libmysqlclient-dev installiert war, dann dürften die noch den alten Pfad haben.


    Wie baust du dir epgd? Das Quellpaket für focal müsste eigentlich auch unter Debian baubar sein und sollte bei der Installation des mariadb-plugin-epglv automatisch die UDF droppen und wieder neu hinzufügen (vorausgesetzt, dass root über den Unix-Socket ohne Passworteingabe mit MariaDB reden darf).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hab es soweit hinbekommen, ich hatte in einer my.cnf im Mysql Verzeichnis einen Pfad gesetzt. Da ich so alles über conf.d Dateien mache hab ich diesen Zusatz nicht berücksichtigt der mariadb.cnf wo geladen wird, scheinbar liest mariadb nicht nur eine vorhandene im Home-Verzeichnis ein, etwas unglücklich beschrieben....:


    Code
    # The MariaDB configuration file
    #
    # The MariaDB/MySQL tools read configuration files in the following order:
    # 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
    # 2. "/etc/mysql/conf.d/*.cnf" to set global options.
    # 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
    # 4. "~/.my.cnf" to set user-specific options.

    Gruß utiltiy



    VDR Projekte VDR Projects

  • FYI


    So wie es aussieht hat die Ausrollung von mariadb 10.5 begonnen bei Debian / Testing über Nacht. Toller Zufall oder nicht, das Plugin Verzeichnis hat sich geändert von:

    /usr/lib/x86_64-linux-gnu/mariadb19/plugin

    zu:

    Code
    mysql_config --plugindir
    /usr/lib/x86_64-linux-gnu/libmariadb3/plugin

    und

    Code
    mysql -u root -p -e "SELECT @@plugin_dir;"
    Enter password: 
    +------------------------+
    | @@plugin_dir           |
    +------------------------+
    | /usr/lib/mysql/plugin/ |
    +------------------------+

    bei beiden Systemen mit mariadb so umgestellt....

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Das Quellpaket für focal müsste eigentlich auch unter Debian baubar sein und sollte bei der Installation des mariadb-plugin-epglv automatisch die UDF droppen und wieder neu hinzufügen (vorausgesetzt, dass root über den Unix-Socket ohne Passworteingabe mit MariaDB reden darf).

    Das funktioniert auch soweit ;)


    Hab nur in den *.service die Bedingung:

    After=vdr.service

    entfernt, da es ein reiner Serverdienst ist, ohne VDR.


    Damit das Plugin an den richtigen Ort kommt, ab MariaDB 10.5 bei Debian ist die Anpassung vom Pfad nötig in mariadb-plugin-epglv.install:

    Code
    #usr/lib/*/mariadb*/plugin/mysqlepglv.so
    usr/lib/*/libmariadb*/plugin/mysqlepglv.so usr/lib/mysql/plugin


    Das Plugin mariadb-plugin-epglv.postinst hab ich ebenfalls angepasst, da PW vorhanden:

    Bash
    #!/bin/sh
    set -e
    
    if [ "$1" = "configure" ]; then
        #mysql < /usr/lib/epgd/mariadb-plugin-epglv.sql ||:
        mysql --defaults-file=/etc/mysql/debian.cnf < /usr/lib/epgd/mariadb-plugin-epglv.sql ||:
    fi
    
    #DEBHELPER#

    damit funktioniert die Installation ohne PW Nachfrage ;)

    Gruß utiltiy



    VDR Projekte VDR Projects

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!