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

utiltiy · Nov 18th 2020

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:

Code

ii libmariadb-dev 1:10.3.24-2 amd64 MariaDB database development files
ii libmariadb-dev-compat:amd64 1:10.3.24-2 amd64 MariaDB Connector/C, compatibility symlinks
ii libmariadb3:amd64 1:10.3.24-2 amd64 MariaDB database client library
ii libmariadbclient-dev:amd64 1:10.3.24-2 amd64 MariaDB database development files (transitional package)
ii mariadb-client-10.3 1:10.3.24-2 amd64 MariaDB database client binaries
ii mariadb-client-core-10.3 1:10.3.24-2 amd64 MariaDB database core client binaries
ii mariadb-common 1:10.3.24-2 all MariaDB common metapackage
ii mariadb-plugin-epglv 1.1.165-0testing0~debian amd64 mariadb plugin epglv (used by epgd)
ii mariadb-server 1:10.3.24-2 all MariaDB database server (metapackage depending on the latest version)
ii mariadb-server-10.3 1:10.3.24-2 amd64 MariaDB database server binaries
ii mariadb-server-core-10.3 1:10.3.24-2 amd64 MariaDB database core server files

Display More

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?

utiltiy · Nov 25th 2020

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?

wmautner · Nov 25th 2020

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.

utiltiy · Nov 25th 2020

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.

utiltiy · Nov 25th 2020

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?

Fourty2 · Nov 25th 2020

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

utiltiy · Nov 25th 2020

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...

seahawk1986 · Nov 25th 2020

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).

utiltiy · Nov 25th 2020

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.

utiltiy · Nov 26th 2020

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....

utiltiy · Nov 29th 2020

seahawk1986 wrote:

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:

Shell-Script

#!/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

Share