configdb crasht FHEM

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

Vorheriges Thema - Nächstes Thema

betateilchen

Was ich gerade nicht verstehe: wenn Du mit configDB arbeitest und Du in Deinem Modul wie bisher  mit FileWrtite() arbeitest, sollten diese Dateien eigentlich automatisch in der Datenbank landen, nicht im Dateisystem.
Dem Mechanismus zum Auflisten der Dateien ist das aber egal.



Was liefert

{FW_confFiles(1)}
-----------------------
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 05 Februar 2023, 07:11:26
Und die entsprechende Zeile im Attribut editFileList lautet bei mir
Configuration files:$FW_confdir:^(.*conf|.*cnf|.*FILE|.*txt)$

Der Eintrag funktioniert zumindest problemlos, wenn ich den bei mir einbaue. Siehe Screenshot.

Wenn

  • die Dateinamen in %data korrekt stehen
  • die Dateien in ./conf vorhanden sind
  • die Angabe in editFileList korrekt ist

und trotzdem der Abschnitt nicht unter "Edit Files" auftaucht, fällt mir als einzige Ursache nur noch ein, dass FHEM in dem Verzeichnis keine Dateien findet. Hat eventuell das Verzeichnis selbst irgendein Rechteproblem, sodaß FHEM dort einfach nicht nachschauen kann, welche Dateien da liegen?

Versuch doch mal, eine in ./conf liegende Datei in die configDB zu importieren und schau nach, ob diese Datei dann zum Editieren angeboten 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

#17
Zum ersten Post oben: Weil ich die Dateien mit FileWrite({FileName => $filename,ForceType => "file"},$json); explizit ins Dateisystem, nicht in die configDB schreibe. Um erstmal ein Problem weniger zu haben. Außerdem ist auf dem einfachen RPi-Testsystem keine configDB da, sondern eine schön traditionelle fhem.cfg.

{FW_confFiles(1)} liefert
Zitat(YAAHMFILE|demo.conf)

Zum zweiten Post: Keine Änderung.

Ich werde gleich nach dem Frühstück mal sehen, ob ich das in der 01_FHEMWEB.pm irgendwie verfolgen kann.

LG

pah

betateilchen

Warum machst Du Dir das Leben unnötig schwer? Da habe ich Dich wohl weiter oben zu früh für die korrekte Verwendung von FileWrite() gelobt...
Lass das mit dem ForceType bitte weg und benutze FileWrite() genau so wie vorher,
Wenn auf dem FHEM keine configDB verwendet wird, landen die Dateien automatisch im Dateisystem.
Genau dafür wurden diese File...() Funktionen ja geschaffen: damit sich ein Entwickler keine Gedanken über die Fallunterscheidung machen muss.

Testweise kannst Du in 01_FHEMWEB.pm in der Funktion FW_displayFileList() eine Debug Meldung einbauen, um das Problem weiter zu analysieren.


sub
FW_displayFileList($@)
{
  my ($heading,@files)= @_;
++  Debug "dFL $heading ".join("|",@files);


Damit sollten auf jeden Fall Debug Ausgaben erzeugt werden, wenn Du im Frontend in den Bereich Edit Files wechselst.
-----------------------
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

ZitatWarum machst Du Dir das Leben unnötig schwer?
Wieso schwer? Wenn man - und das kannst Du einem, den auf dem Gebiet NLP aktiv forscht, nicht verwehren - z.B. das babbleFILE mit einem externen Werkzeug bearbeiten will, führt daran kein Weg vorbei.

LG

pah

betateilchen

#20
Das mit dem "Leben schwer machen" bezog sich hierauf:

Zitat von: Prof. Dr. Peter Henning am 05 Februar 2023, 09:59:56
Außerdem ist auf dem einfachen RPi-Testsystem keine configDB da, sondern eine schön traditionelle fhem.cfg.

Das alleine wäre kein Grund, mit ForceType zu arbeiten.

Aber wie schon gesagt - dem Mechanismus zum Auflisten von Konfigurationsdateien ist es egal, ob die Datei im Dateisystem liegt oder in der Datenbank.
-----------------------
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

Skype geht heute morgen nicht, ich muss gleich arbeiten...

Ich habe es jetzt zumindest eingegrenzt. 01_FHEMWEB steigt hier aus

Zitatsub
FW_fileList($;$)
{
  my ($fname,$mtime) = @_;
  my $logdir = Logdir();
  $fname =~ s/%L/$logdir/g; #Forum #89744
  $fname =~ m,^(.*)/([^/]*)$,; # Split into dir and file
  my ($dir,$re) = ($1, $2);
  Debug "===========> fL dir=$dir,    re=$re";
  return $fname if(!$re);
  $re =~ s/%./[A-Za-z0-9]*/g;    # logfile magic (%Y, etc)
  my @ret;
  Debug "==========> fL before opendir $dir";
return @ret if(!opendir(DH, $dir));
  Debug "==========> fL opendir $dir succesfull";
  while(my $f = readdir(DH)) {
    next if($f !~ m,^$re$, || $f eq "98_FhemTestUtils.pm" ||
                              $f eq "99_Utils.pm");
    push(@ret, $f);
  }
  closedir(DH);
  return sort { (CORE::stat("$dir/$a"))[9] <=> (CORE::stat("$dir/$b"))[9] }
         @ret if($mtime);
  @ret = cfgDB_FW_fileList($dir,$re,@ret) if (configDBUsed());
  return sort @ret;
}

Darüber hinaus habe ich auch noch eine weitere Datei zum Editieren in die editFileList eingebaut, mit Namen phonebook.txt. Und das klappt prima, wird mir zum Editieren angeboten.

Die Ausgabe in Log ist

Zitat
DEBUG>=============> t=Helper files,  v=/opt/fhem/FHEM,   re=^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday|.*sh)$
2023.02.05 11:01:23 1: DEBUG>===========> fL dir=/opt/fhem/FHEM,    re=^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday|.*sh)$
2023.02.05 11:01:23 1: DEBUG>==========> fL before opendir /opt/fhem/FHEM
2023.02.05 11:01:23 1: DEBUG>==========> fL opendir /opt/fhem/FHEM succesfull
2023.02.05 11:01:23 1: DEBUG>===========> filelist=99_BabbleUtils.pm,99_HeatingUtils.pm,99_LightUtils.pm,99_PlotUtils.pm,99_RemoteUtils.pm,99_RollUtils.pm,99_SecUtils.pm,99_TimeUtils.pm,99_myUtils.pm,calendar.cfg,ebus_hz.cfg,ebus_solar.cfg,ebus_ww.cfg,holiday,holiday/Ferien.holiday.configDB


2023.02.05 11:01:23 1: DEBUG>=============> t=Configuration files,  v=/opt/fhem/conf,   re=^(.*conf|.*cnf|.*FILE|.*txt)$
2023.02.05 11:01:23 1: DEBUG>===========> fL dir=/opt/fhem/conf,    re=^(.*conf|.*cnf|.*FILE|.*txt)$
2023.02.05 11:01:23 1: DEBUG>==========> fL before opendir /opt/fhem/conf
2023.02.05 11:01:23 1: DEBUG>===========> filelist=


2023.02.05 11:01:23 1: DEBUG>=============> t=Phonebook,  v=/opt/fhem/FHEM,   re=^phonebook.txt$
2023.02.05 11:01:23 1: DEBUG>===========> fL dir=/opt/fhem/FHEM,    re=^phonebook.txt$
2023.02.05 11:01:23 1: DEBUG>==========> fL before opendir /opt/fhem/FHEM
2023.02.05 11:01:23 1: DEBUG>==========> fL opendir /opt/fhem/FHEM succesfull
2023.02.05 11:01:23 1: DEBUG>===========> filelist=phonebook.txt


So, und jetzt sag mir einer, was da los ist. Das Verzeichnis /opt/fhem/config hat als owner fhem:dialout, und als Rechte habe ich 755, 775 und 777 ausprobiert. Leicht irre finde ich, dass FileWrite und FileRead damit gut zurecht kommen - aber opendir nicht.

LG

pah

betateilchen

Zitat von: betateilchen am 05 Februar 2023, 09:25:01
fällt mir als einzige Ursache nur noch ein, dass FHEM in dem Verzeichnis keine Dateien findet. Hat eventuell das Verzeichnis selbst irgendein Rechteproblem, sodaß FHEM dort einfach nicht nachschauen kann, welche Dateien da liegen?

Da war meine Vermutung mit dem Rechteproblem doch gar nicht so falsch.
Ein ähnliches Problem hatte ich irgendwann, als ich versucht hatte, ein Verzeichnis aus FHEM mit make_path() aus File::Path anzulegen.

Wie hast Du denn (aus Deinem Modul heraus?) das Verzeichnis ./conf angelegt?
-----------------------
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

#23
(mit schlechtem Gewissen, weil ich eigentlich wirklich die Klausur korrigieren muss...) Beispielsweise so.
    my $error = mkdir $filedir;
     if( $error != 1){
       Log3 $name,1,"[Alarm_save] configuration directory $filedir could not be created, return code=$error";

Und ich habe es gerade eben auch nochmal mit einem manuell angelegten Verzeichnis probiert.

Irre. => Gelöst

LG

pah

betateilchen

Lass Dich nicht bei der Arbeit stören, ich sammle hier noch ein paar Ergebnisse meiner weiteren Tests.

Deine Art der Fehlerbehandlung hat natürlich den Effekt, dass jetzt immer eine Fehlermeldung im Log ausgegeben wird, da ein Verzeichnis ja nur einmal angelegt werden kann.

Bei mir habe ich jetzt das ./conf Verzeichnis wieder gelöscht und in meine 99_myUtils.pm folgendes eingebaut:


sub test{
   use File::Path qw(make_path);
   my $pathname = AttrVal('global','modpath','.').'/conf';
   my @result   = make_path($pathname, { verbose => 1, chmod => 0755, owner => 'fhem', group => 'dialout'});
   my $ret  = "make_path result:\n".join("\n",@result);
   my $filename = $pathname."/myUtils.conf";
   my $err  = FileWrite({ FileName => $filename, ForceType => "file"},"test");
      $err  = $err?$err:"ok";
      $ret .= "\n\nFileWrite result: $err";
      $err  = opendir(DH, $pathname) ? "ok" : "error";
      $ret .= "\n\nopendir result: $err";
   while(my $f = readdir(DH)) {
      $ret .= "\nfound :$f";
   }
   closedir(DH);
   $ret .= "\n\nFW_fileList result:\n";
   @result = FW_fileList("$pathname/.*conf");
   $ret .= join("\n",@result);
   return $ret;
}


Ein Aufruf der Funktion liefert hier folgendes Ergebnis:


make_path result:
./conf

FileWrite result: ok

opendir result: ok
found :.
found :..
found :myUtils.conf

FW_fileList result:
myUtils.conf
myUtils.conf.configDB


Anschließend wird die Datei unter Edit Files angezeigt (sogar zweimal, einmal aus dem Dateisystem und einmal die Version in der Datenbank, das ist aber für den Test unbedeutend)

Mit dem Wert 0644 in make_path hat das Ganze nicht funktioniert, da gab es einen Fehler beim FileWrite.
-----------------------
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

#25
ZitatDeine Art der Fehlerbehandlung hat natürlich den Effekt, dass jetzt immer eine Fehlermeldung im Log ausgegeben wird, da ein Verzeichnis ja nur einmal angelegt werden kann.
Äh, nö. Das war nur ein Schnipsel aus dem Code, natürlich schaue ich vorher, ob das Verzeichnis existiert:
#-- check existence of config directory
  my $filedir = $attr{global}{modpath}."/conf";
  if (-d $filedir) {
     Log3 $name,1,"[Alarm_save] configuration directory $filedir found";
  }elsif (-e "$filedir") {
     Log3 $name,1,"[Alarm_save] $filedir found, but is not a directory";
     return 1;
  }else {
     my $error = mkdir $filedir;
     if( $error != 1){
       Log3 $name,1,"[Alarm_save] configuration directory $filedir could not be created, return code=$error";
       return 1;
     }
     Log3 $name,1,"[Alarm_save] configuration directory $filedir created";
  }


(brauchte mal eine Sekunde Pause vom Korrigieren...)

LG

pah

betateilchen

Auch wenn ich mkdir für sowas nicht mag (es arbeitet im Unterschied zu make_path nicht rekursiv), habe ich meinen o.g. Test jetzt nochmal mit mkdir ausgeführt.

Auch hier war das Ergebnis erfolgreich.
Warum es bei Dir nicht funktioniert - da bin ich gerade etwas ratlos.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Jamo

Kann es sein, das der benutzte Style einen Einfluss hat?
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

betateilchen

Zitat von: Jamo am 05 Februar 2023, 18:41:28
Kann es sein, das der benutzte Style einen Einfluss hat?

Das würde mich sehr wundern.

bright, dark, f11, f18, iOS6, iOS7, iOS12 - alle getestet, in allen werden mir die Dateien zum Bearbeiten angeboten.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Eigentlich sollte ein Moderator diesen Thread mal auftrennen.
Das Problem mit den Konfigurationsdateien hat ja schon lange nichts mehr mit dem ursprünglichen Theman und dem Titel zu tun.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!