configdb crasht FHEM

Begonnen von Prof. Dr. Peter Henning, 02 Februar 2023, 07:15:50

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Ich habe wie immer im Januar den neuen Müllkalender eingelesen, und als Datei /opt/fhem/muell.ics in die configdb importiert. Nachdem das dennoch nicht richtig funktionierte, habe ich mit configdb filelist nachgesehen: Außer der Datei /opt/fhem/muell.ics behauptet configdb auch noch eine Datei muell.ics zu enthalten, die - folgerichtig - die Daten aus dem letzten Jahr enthält und bei der Anforderung aus dem Müllkalender als erstes gelesen wird. Kann also nicht gehen...

Also habe ich zuerst den Befehl configdb filedelete muell.ics abgesetzt. Daraufhin teilt mir configdb brav mit, dass es die Datei /opt/fhem/muell.ics gelöscht habe - die ich ja gar nicht löschen wollte. Also noch einmal configdb filedelete muell.ics. Daraufhin teilt mir configdb mit
ZitatFile /opt/fhem/muell.ics not found in database.
Allerdings ergibt configdb fileshow muell.ics sehr wohl den Inhalt der veralteten Datei. Hier stimmt also etwas nicht - wie werde ich die obsolete Datei wieder los?

Dann habe ich verschiedene Varianten des Dateinamen muell.ics ausprobiert. Alle ohne Erfolg, bis ich dann  configdb filedelete 'muell.ics' eingegeben habe. Daraufhin hat sich FHEM ins Nirvana verabschiedet. Fehlermeldung:
Zitat2023.02.02 06:57:49 1: PERL WARNING: DBD::SQLite::db do failed: near "muell": syntax error at configDB.pm line 1340.
DBD::SQLite::db do failed: near "muell": syntax error at configDB.pm line 1340.

LG

pah

betateilchen

Moin Peter,

der reißerische Thread-Titel

Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
configdb crasht FHEM

ärgert mich gerade maßlos.


  • Wenn Dein Rottweiler ein kleines Kätzchen frißt und daran erstickt, ist auch nicht das kleine Kätzchen schuld, sondern der Hund, weil er etwas getan hat, das er nicht tun sollte. Genau so ist das hier:

    Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
    bis ich dann configdb filedelete 'muell.ics' eingegeben habe

    Du hast etwas getan, was man nicht tun sollte. Es steht nirgends, dass man den Dateinamen in dem Befehl in Anführungszeichen setzen soll  :)

  • Der Titel hat überhaupt nichts mit dem eigentlichen Problem zu tun, für das Du eine Lösung suchst. Dein Problem ist ja nicht der von Dir provozierte FHEM Absturz, sondern dass Du eine Datei nicht löschen kannst.




Kommen wir zu Deiner Frage:

Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
und als Datei /opt/fhem/muell.ics in die configdb importiert.
...
Nachdem das dennoch nicht richtig funktionierte
...
Außer der Datei /opt/fhem/muell.ics behauptet configdb auch noch eine Datei muell.ics zu enthalten, die - folgerichtig - die Daten aus dem letzten Jahr enthält und bei der Anforderung aus dem Müllkalender als erstes gelesen wird. Kann also nicht gehen...

Wenn die Datei im Vorjahr muell.ics hieß und Du die neue Datei dieses Jahr als /opt/fhem/muell.ics importiert hast, sind das für configDB zwei unterschiedliche Dateien. Hier wird nämlich nicht mit Pfaden im Sinne eines Dateisystems gearbeitet, sondern der angegebene Name inklusive Pfad identifiziert die abgespeicherte Datei eindeutig.

Dateien OHNE Pfadangabe können zwar in die Datenbank importiert werden, solche Dateien können aber mit configdb filedelete nicht gelöscht werden. Beides ist so beabsichtigt, auf die Hintergründe und Notwendigkeiten dafür will ich jetzt nicht eingehen.

Wenn Dein Müllkalender nach einer Datei muell.ics (ohne Pfadangabe) sucht, dann importiere doch die ics Datei einfach aus dem Verzeichnis /opt/fhem mittels
configdb fileimport muell.ics
in die Datenbank, dann wird die vorherige Datei durch die neue ersetzt.

Alternativ kannst Du die Datei als /opt/fhem/muell.ics importieren, dann musst Du halt in Deinem Müllkalender die Datei dort auch genau so angeben.

Eine Datei ohne Pfadangabe kannst Du nur auf Datenbankebene außerhalb FHEM aus der configDB löschen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Habe gerade nochmal in meinem code nachgeschaut.

Zitat von: betateilchen am 02 Februar 2023, 08:38:19
Dateien OHNE Pfadangabe können zwar in die Datenbank importiert werden

Mach mal bitte ein "configdb filelist" - mich interessieren nur die Zeilen, die muell.ics enthalten.
Eigentlich kann eine Datei vom Benutzer gar nicht ohne Pfadangabe importiert werden.

Wenn Du beispielsweise "configdb fileimport muell.ics" eingibst, wird der Dateiname automatisch um den in global definierten modpath ergänzt. In der Datenbank wird die Datei dann als ./muell.ics abgelegt. Das ist genau aus dem Grund so implementiert, damit die Datei auch vom Benutzer wieder mit "configdb filedelete ./muell.ics" gelöscht werden kann.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
Dann habe ich verschiedene Varianten des Dateinamen muell.ics ausprobiert. Alle ohne Erfolg, bis ich dann  configdb filedelete 'muell.ics' eingegeben habe. Daraufhin hat sich FHEM ins Nirvana verabschiedet.

Sollte ab dem morgigen Update nicht mehr passieren.

https://forum.fhem.de/index.php/topic,131996.0.html
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Prof. Dr. Peter Henning

Lieber Udo,

den "Ärger" kannst Du bitte, in aller Freundschaft, wieder runterfahren. Auch wenn das nirgendwo steht, müssen wir bei FHEM immer vom DAU, dem dümmsten anzunehmenden User ausgehen. Und der sollte nicht durch einen einfachen FHEM-Befehl sein System zum Absturz bringen können, und schon gar nicht mit einer Fehlermeldung "Syntaxfehler". Wenn das beim nächsten Update gefixt ist, prima.

Betreffend configdb filelist:
ZitatFiles found in database:
------------------------------------------------------------
/home/fhem/fhemlogs/LightScenes.save
... diverse weitere Dateien mit Pfadangabe
/opt/fhem/www/gplot/well.gplot
441327ce3704eee20587a97ab5b996de.fhem.save
... diverse weitere save-Files
9d55dcecde2d6c66906f411f3b86608d.fhem.save
AlarmFILE
TESTFILE
YAAHMFILE
babbleFILE
muell.ics

Also, wie Du siehst: mehrere Files OHNE Pfadangabe. AlarmFILE, YAAHMFILE, babbleFILE sind Konfiurationsdateien für meine Module und fühlen sich in der configdb sehr wohl - aber hineingeschrieben habe _ich_ sie nicht, und löschbar sind sie auch nicht. Und muell.ics _ohne_ "./", auch nicht löschbar. 

LG

pah


betateilchen

#5
Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 15:10:03
müssen wir bei FHEM immer vom DAU, dem dümmsten anzunehmenden User ausgehen.
Und der sollte nicht durch einen einfachen FHEM-Befehl sein System zum Absturz bringen können, und schon gar nicht mit einer Fehlermeldung "Syntaxfehler".

Bei einem "Prof. Dr." gehe nicht von einem "dümmsten anzunehmenden User" aus. Und von allen anderen Usern ist in den vergangenen fast 9 Jahren, seit es configDB gibt, noch nie jemand auf die Idee gekommen, den Dateinamen in Anführungszeichen zu setzen. Wahrscheinlich bist Du einfach überqualifiziert und alle anderen waren zu dumm, auf diese Idee zu kommen.

Davon abgesehen, ist die Fehlermeldung aus der Datenbankschicht (außerhalb FHEM!), die auf den Syntaxfehler hinweist, völlig korrekt.

Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 15:10:03
Betreffend configdb filelist:
Also, wie Du siehst: mehrere Files OHNE Pfadangabe. AlarmFILE, YAAHMFILE, babbleFILE sind Konfiurationsdateien für meine Module und fühlen sich in der configdb sehr wohl
- aber hineingeschrieben habe _ich_ sie nicht, und löschbar sind sie auch nicht. Und muell.ics _ohne_ "./", auch nicht löschbar. 

Das ist aber eher ein Problem der Module, die diese Dateien angelegt haben und damit arbeiten. Beispiel aus 95_Alarm.pm, Zeile 509:

my $error  = FileWrite("AlarmFILE",$jhash0);

Würden diese (alles Deine?) Module beim Anlegen der Dateien korrekt das globale Attribut modpath berücksichtigen und verwenden, gäbe es das Problem nicht.

Zugegeben: Dieses Problem tritt in dieser Form erstmalig auf. Aber man kommt beim besten Willen nicht darauf, dass ein Entwickler eine Konfigurationsdatei einfach ohne eine Pfadangabe (./ würde ausreichen!) IRGENDWOHIN schreibt - schon gar nicht ins root-Verzeichnis von FHEM (bezogen auf ein Dateisystem). Vor vier Jahren (Januar 2019) wurde im Developmentbereich das Thema "Ablage von Konfigurationsdateien" diskutiert und dabei auch ein Konfigurationsverzeichnis ./conf definiert, das dafür verwendet werden kann. Das schafft sogar die Möglichkeit, die dort abgelegten Dateien über "Edit files" bearbeitbar zu machen. Die Verantwortung, das Verzeichnis zu verwenden bzw. dieses Verzeichnis anzulegen, wenn es noch nicht vorhanden ist, liegt beim Modulautor, der dort seine Konfigurationsdateien ablegen möchte.


-
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: betateilchen am 02 Februar 2023, 16:46:08
Das ist aber eher ein Problem der Module, die diese Dateien angelegt haben und damit arbeiten.

Nun habe ich mal FHEM durchforstet.
Es gibt genau drei Module, die dieses Problem verursachen,
weil sie mit einem Dateinamen ohne Pfadangabe arbeiten:


95_Alarm.pm in Zeile 509
95_Babble.pm in Zeile 459
95_YAAHM.pm in Zeile 1030


Die Datei "muell.ics" ist vermutlich auf einem anderen Weg in die Datenbank gekommen, vielleicht in einer 99_myUtils.pm?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Prof. Dr. Peter Henning

Erst einmal danke für den Hinweis, wie ich das Ding wieder loswerde - das war mir wichtig.

Zweitens:
ZitatVor vier Jahren (Januar 2019) wurde im Developmentbereich...
mag ja sein. Aber alle diese Module sind deutlich älter. Und da wir keinen Lesezwang haben, war diese Diskussion bei mir nicht auf dem Schirm. Wenn ich mich recht erinnere, war ich 2019 vollauf damit beschäftigt, neue Forschungsaktivitäten im KI-Bereich hochzufahren, die seitdem einen erheblichen Teil meiner Zeit beanspruchen. Ist aber ein guter Hinweis, ich werde alle drei entsprechenden Module so umbauen.

Drittens:
ZitatBei einem "Prof. Dr." gehe nicht von einem "dümmsten anzunehmenden User" aus.
Andersherum. Ich war mal Chef des Test-Teams einer Tochtergesellschaft der Deutschen Börse AG und habe da gelernt, systematische DAU-Tests durchzuführen.

LG

pah

betateilchen

Zitat von: Prof. Dr. Peter Henning am 03 Februar 2023, 05:38:44
Ist aber ein guter Hinweis, ich werde alle drei entsprechenden Module so umbauen.

Für den Anfang würde als Sofortmaßnahme reichen, jeweils das aktuelle Verzeichnis als Pfad mit anzugeben:

my $error  = FileWrite("./AlarmFILE",$jhash0);

An den Stellen, an denen das File gelesen wird, muss das natürlich auch so angepasst werden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Prof. Dr. Peter Henning

#9
Ich habe mal mit einem einfachen grep gesucht - aber bisher kein Modul gefunden, das ein "conf"-Directory testet und ggf. erzeugt... War wohl 2019 doch nicht so dringend.

LG

pah

Edit: Ich habe das gerade in Babble, YAAHM und Alarm eingebaut.

betateilchen

Dringend? Habe ich nie behauptet. Aber nützlich. Es gibt aber durchaus Module außerhalb des offiziellen FHEM Kosmos, und da hilft Dir auch Dein grep nicht weiter. Bei mir gibt es aktuell vier Module, die mit ./conf arbeiten und das funktioniert super.

Vermutlich wissen einfach zu wenige Entwickler überhaupt von dem bunten Strauß an Möglichkeiten, die tief im Inneren von FHEM inzwischen verborgen schlummern. Wenn ich mir anschaue, welche Klimmzüge manche Module machen, um eigene Dateien zu verwalten, könnte es mancher Entwickler sehr viel leichter haben, wenn man auf solche Mechanismen zurückgreifen würde.  Oft ist es hilfreich, ab und zu mal in die fhem.pl zu schauen, um zu verstehen, wofür es alles fertige Funktionen gibt. Genauso wäre es an manchen Stellen hilfreich, wenn die Kollegen die Funktionen FileWrite() etc. "richtig" verwenden würden, damit sie auch den Zweck erfüllen, zu dem sie ursprünglich erschaffen wurden. Aber diese Diskussion gehört eigentlich nicht in diesen Thread, zumal Du es ja prinzipiell richtig machst (abgesehen vom Dateinamen ohne Pfad).

Das ./conf Verzeichnis und das Problem in Deinen drei Modulen haben nicht zwingend etwas miteinander zu tun.
Es würde schon reichen, wenn Du in Deinen Modulen beim Schreiben und Lesen der Datei den in FHEM global definierten modpath vor den Dateinamen setzen würdest.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Prof. Dr. Peter Henning

#11
ZitatEs würde schon reichen,

Halbe Sachen mache ich nicht.

ZitatVermutlich wissen einfach zu wenige Entwickler

Stimmt. Aber ich habe weder die Zeit, allen Threads zu folgen, noch, die fhem.pl zu studieren. Die Sache mit dem ./conf hätte m.E. auch unter Ankündigungen erscheinen sollen. Und wir sollten so etwas wie einen "Developer Alert" einrichten, der solche Dinge zumindest einem eingeschränkten Personenkreis bekannt macht.

LG

pah

Prof. Dr. Peter Henning

#12
Das mit dem Lesen und schreiben in ./conf klappt prima - aber bisher kriege ich keine der Dateien im 01_FHEMWEB zum Editieren angezeigt, obwohl ich a.) sie in $data{confFiles} eingetragen habe und b.) sie auch explizit in der editFileList des Frontends habe und c.) diverse Endungen des Dateinamens ausprobiert habe.

LG

pah

betateilchen

Moin Peter,

zu a) in meiner 99_myUtils.pm habe ich testweise folgendes eingetragen: $data{confFiles}{'myUtils.conf'} = '0';

Danach wird mir die Datei myUtils.conf zu Editieren angeboten, sofern die Datei existiert. Siehe angehängten Screenshot

zu b) für meinen Test in a) habe ich eine Installation verwendet, die kein Attribut editFileList besitzt. Für die Anzeige der Konfigurationsdateien müssen diese nicht extra angegeben werden.

Falls Du das Attribut editFileList selbst gesetzt hast, sollte der Eintrag für die Konfigurationsdateien so aussehen

"Config files for external programs:\$FW_confdir:^".FW_confFiles(1)."\$\n"

zu c) die Endungen der Dateien haben keinen Einfluss. Es wird exakt der Dateiname verwendet, der in $data{confFiles} angegeben wird.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Prof. Dr. Peter Henning

#14
Hab ich alles brav gemacht:

{Dumper($data{confFiles})} ergibt
Zitat$VAR1 = {
          'demo.conf' => '0',
          'YAAHMFILE' => '0'
        };

ls -l /opt/fhem/conf
ergibt
Zitattotal 28
-rw-r--r-- 1 fhem dialout  292 Feb  4 10:28 Alarm.conf
-rw-r--r-- 1 fhem dialout  292 Feb  3 20:13 AlarmFILE
-rw-r--r-- 1 fhem dialout    4 Feb  4 10:22 demo.conf
-rw-r--r-- 1 fhem dialout 5078 Feb  4 10:28 YAAHM.cfg
-rw-r--r-- 1 fhem dialout 5062 Feb  5 00:00 YAAHMFILE

Und die entsprechende Zeile im Attribut editFileList lautet bei mir
Configuration files:$FW_confdir:^(.*conf|.*cnf|.*FILE|.*txt)$

Ergbnis: Keine Anzeige der existierenden und registrierten Dateien wird zum Editieren angezeigt. Versucht auf zwei verschiedenen Systemen, erstens einem meiner Hauptsysteme und zweitens auf einem Minimalsystem mit RaspBerry Pi und fast keinen Devices und ohne editFileList Attribut. In beiden Fällen ist die Version von 01_FHEMWEB aktuell.  :'(

LG

pah