FHEM Absturz wenn configDB nicht erreichbar

[crispyduck]

Wenn die Konfigurationsdatenbank nicht erreichbar ist (im einfachsten Fall beim FHEM Start) gibt es auch noch kein Log-Device, in das man irgendwas loggen könnte. Denn auch das define für das Logfile steht in der Konfiguration.

Ich habe ja auch nicht vom Start gesprochen, dafür hab ich ja auch extra die Zeile im init.d script eingef ügt die FHEM erst startet wenn die DB erreich ar ist.
Es reicht ja im prinzip auch aus wenn FHEM als Service automatisch neu gestartet wird. Trotzdem finde ich es nicht ganz schön das sich FHEM einfach beendet.

Nein, ich werde weder einen timeout noch einen reconnect einbauen. Und ausser Dir hatte damit bis heute auch noch nie irgendjemand ein Problem. Wenn Du Deine Datenbank im laufenden Betrieb abschießt, ist das kein Problem, um das ich mich als Entwickler der configDB kümmern will (und auch nicht muss).

Es hat keiner gesagt das du etwas einbauen musst. Und naja, es gibt immer ein erstes mal. 

Wenn bei Dir der Strom ausfällt, ist das auch nicht mein Problem.

Verstehe nicht weshalb du jetzt so aggressiv auf meine Frage reagierst, ich habe weder dich noch deine Arbeit kritisiert. Ganz im Gegenteil ich finde deine Arbeit und vor allem auch die configdb super und bin dir dankbar das du deine Arbeit mit allen teilst.
Ich befasse mich auch noch nocht lange mit FHEM und bin auch noch nicht sehr weit. Vorallem da ich von der Idee die config als auch alle config files in der DB zu speichern begeistert bin und mich daher erst einmal trotz fehlender Programmierkenntnisse damit beschäftigt habe die eingesätzten Module configdb tauglich zu machen.

Kann dir nur für deine Arbeit danken; und ein einfaches nein geht nicht, macht keinen Sinn,... hätte auch gereicht!

Lg
Crisoyduck

[crispyduck]

Hallo,

möchte nochmal vorsichtig fragen ob etwas dagegen spricht folgendes in der sub _cfgDB_Connect() zu ändern um FHEM nicht abstürzen zu lassen und stattdessen mit Timeout auf eine erfolgreiche Verbindung zu warten:

Code Auswählen Erweitern

# connect do database
sub _cfgDB_Connect() {
my $fhem_dbh = DBI->connect(
"dbi:$cfgDB_dbconn",
$cfgDB_dbuser,
$cfgDB_dbpass,
{ AutoCommit => 0, RaiseError => 1 },
) or die $DBI::errstr;
return $fhem_dbh;
}

zu

Code Auswählen Erweitern

# connect do database
sub _cfgDB_Connect() {
my $fhem_dbh;
until (
$fhem_dbh = DBI->connect(
"dbi:$cfgDB_dbconn",
$cfgDB_dbuser,
$cfgDB_dbpass,
{ AutoCommit => 0, RaiseError => 0, PrintError => 0 },)
)
{
Log3 'configDB', 1, "configDB: $DBI::errstr. Pausing 60 seconds before retrying.";
          sleep 60;
  }
  $fhem_dbh->{RaiseError} = 1;
return $fhem_dbh;
}

FHEM stürzt somit zumindest nicht ab und versucht alle 60 sec sich wieder mit der DB zu verbinden.
Im Logfile sieht man somit dann auch wann die DB weg war.

Lg,
Crispyduck

[Benni]

Blockiert FHEM dann nicht auch die kompletten 60 Sekunden?

[crispyduck]

Hi Benni,

Ja, blockiert dann auch die 60 Sekunden. Könnte natürlich auch 5 Sekunden oder weniger draus machen.

Ist aber in dem Zustand egal, da ja ohnehin die configDB nicht erreichbar ist und alternativ "or die" kommt und somit FHEM ohnehin komplett beendet wäre.

Lg
Crispyduck

[betateilchen]

Trotzdem finde ich es nicht ganz schön das sich FHEM einfach beendet.

Dieses Verhalten habe ich absichtlich so eingebaut.

fragen ob etwas dagegen spricht

Ja. Zum einen die Tatsache, dass ich das absichtlich so eingebaut habe, zum anderen gibt es auch technische Gründe. Wobei der erste Halbsatz sich als Ergebnis aus dem zweiten Halbsatz ableitet.

[Benni]

@crispyduck: ich würde mich an deiner Stelle auch eher mal mit meinem Datenbankkonzept beschäftigen. Da wäre die Zeit schätzungsweise  besser investiert..

[crispyduck]

Hi,

quote author=betateilchen link=topic=72034.msg636690#msg636690 date=1495041433]
Ja. Zum einen die Tatsache, dass ich das absichtlich so eingebaut habe, zum anderen gibt es auch technische Gründe. Wobei der erste Halbsatz sich als Ergebnis aus dem zweiten Halbsatz ableitet.

Okay wenn das technische Gründe hat warum du das absichtlichso eingebaut hast verstehe ich das.

Meine Kenntnisse reichen auch nicht aus um die Funktion des ganzen Moduls, oder weitreichendere Auswirkungen zu überschauen.

Habe lediglich geschaut wo sich FHEM mit dem Modul beendet und mir gedacht vielleicht kann mab ja eine. Retry einbauen.

Darf ich dich noch fragen was die technischen Gründe sind, und was man sich mit so einem Retry eventuell alles zerschießen kann?

Danke,
Crispyduck

[crispyduck]

@crispyduck: ich würde mich an deiner Stelle auch eher mal mit meinem Datenbankkonzept beschäftigen. Da wäre die Zeit schätzungsweise  besser investiert..

Ja, aber wüßte nicht was ich da ändern sollte, habe meine DBs absichtlich auf der NAS und diese werden auch noch regelmäßig gesichert. Meine Raspi mit FHEM hängt bei der Heizung im Nebengebäude und ist quasi dumm; zumindest liegt auf ihr keine config (ausser natürlich die für die confugDB) und das Filesystem ist RO.
Die Verbindung zur DB ist ja eigentlich auch immer da, nur zu Maintenance zwecken, also Update,... kann es sein das die DB kurzzeitig nicht erreichbar ist.
Natürlich weiß ich wann das ist und könnte mich ja dann drum kümmern das ich FHEM wieder starte, bzw. sowieso vorher beenden.
Und wenn doch mal was ist wird FHEM ja wenn man es wie betateilchen es beschrieben hat als Service laufen lässt auch automatisch neu gestartet.

Ich habe beruflich auch mit Systemen zu tun, wo die konfiguratuon auch auf zentralen DB servern liegt und sich der Rest vom System, also die anderen Server und Services die config von dort holen. Da gibt es aber unter anderem die Anforderung das dass System auch bei Ausfall der DB zumindest gewisse Zeit ohne beeinträchtigung weiter laufen muss.

Ist aber was ganz was anderes und ich dachte mir eben ursprünglich auch das die configDB nur gebraucht wird um initial die config zu lesen, oder eben wenn die config verändert wird.

Lg
Crispyduck

[amenomade]

möchte nochmal vorsichtig fragen ob etwas dagegen spricht folgendes in der sub _cfgDB_Connect() zu ändern um FHEM nicht abstürzen zu lassen und stattdessen mit Timeout auf eine erfolgreiche Verbindung zu warte

Das wäre m.A. hochgefährlich. Da _cfgDB_Connect an mehrere Stellen gerufen werden kann (FileRead, FileWrite, FileUpdate, SaveCfg, SaveState, Read99, ReadState usw...), ist so ein Timeout die beste Lösung, um auf Dead Locks (Verklemmungen) zu kommen, oder zumindest auf einen blockierenden / gefrorenen  Zustand, der noch schlimmer als ein Absturz (da mögliche Incohärenzen) wäre.

Die Entwickler geben sich Mühe, um so viel wie möglich auf "non blocking" zu setzen; fhem 60 Sek (5 Sek wäre nicht wirklich besser) zu blockieren an einer "tief interne" Stelle ,die so oft vorkommt, scheint mir Blödsinn.

Aber Vorschlag: mach doch die Änderung, wie du es meinst, und guck mal wie FHEM reagiert, wenn du die DB unerreichbar machst Und teste auch wie deine Config überlebt bei einem Neustart nach gefrorenen Zustand.

Natürlich UNSUPPORTED Eh... mach doch ein configdb dump und ein Backup vorher..., möglicherweise wenn die DB noch erreichbar ist    

[crispyduck]

Hallo amenomade!

Das wäre m.A. hochgefährlich. Da _cfgDB_Connect an mehrere Stellen gerufen werden kann (FileRead, FileWrite, FileUpdate, SaveCfg, SaveState, Read99, ReadState usw...), ist so ein Timeout die beste Lösung, um auf Dead Locks (Verklemmungen) zu kommen, oder zumindest auf einen blockierenden / gefrorenen  Zustand, der noch schlimmer als ein Absturz (da mögliche Incohärenzen) wäre.

Das dachte ich mir schon, das es wohl nicht so einfach ist wie ich es mir ursprünglich gedacht hatte.

Aber Vorschlag: mach doch die Änderung, wie du es meinst, und guck mal wie FHEM reagiert, wenn du die DB unerreichbar machst Und teste auch wie deine Config überlebt bei einem Neustart nach gefrorenen Zustand.

Natürlich UNSUPPORTED Eh... mach doch ein configdb dump und ein Backup vorher..., möglicherweise wenn die DB noch erreichbar ist    

Das habe ich natürlich schon probiert und ein paar mal getestet und funktioniert soweit auch. Ist aber auch nicht wirklich aussagekräftig da mein System momentan noch nicht sehr viel konfiguriert hat. Ich frage lediglich einen Modbus Stromzähler und meine Heizung via VCONTROL300 ab.
Beides aber so umgeschrieben das sie die config aus einem cfg file aus der configDb laden.

Lg,
Crispyduck

[Benni]

Das habe ich natürlich schon probiert und ein paar mal getestet und funktioniert soweit auch.

Natürlich "funktioniert" das, wenn man blockierend auf die Rückkehr der Datenbank wartet. So sie denn auch irgendwann wiederkommt, am besten nach nicht all zu langer Wartezeit. Im Endeffekt ist aber so dein komplettes FHEM blockiert, bis die Datenbank wieder erreichbar ist, unabhängig vom Prüfintervall.

Nochmal: wenn ich ein datenbankgestütztes System einsetze, sollte ich tunlichst dafür Sorge tragen, dass die Datenbank in dem Umfang, wie sie benötigt wird auch dem System zur Verfügung steht. Genau daran sollte man auch arbeiten und nicht das System verbiegen, um die Symptome zu behandeln! Dem System geht's dadurch nicht besser, sondern noch schlechter!

Die einfachste Möglichkeit in deinem Fall, nämlich der nicht sichergestellten Datenbankverbindung zum Remotesystem, wäre wohl eine lokale DB. Im einfachsten Fall und für ConfigDB hervorragend geeignet eben eine SQLite-Datenbank.

Jetzt noch ein Backup auf das oder ein anderes Remotesystem (bspw. mittels cron und rsync) und das Problem ist gelöst. Und das ohne einen Eingriff ins System, für den außer dir niemand Bedarf zu haben scheint.

Das ganze funktioniert natürlich auch mit lokalem MySQL und dazugehörigem Remote-Backup.

[crispyduck]

Natürlich "funktioniert" das, wenn man blockierend auf die Rückkehr der Datenbank wartet. So sie denn auch irgendwann wiederkommt, am besten nach nicht all zu langer Wartezeit. Im Endeffekt ist aber so dein komplettes FHEM blockiert, bis die Datenbank wieder erreichbar ist, unabhängig vom Prüfintervall.

Muss ich nochmal erwähnen was alternativ passiert?

Ich habe auch schon erwähnt das ich mein System absichtlich so eingerichtet habe.

Verstehe das Problem nicht. Das Forum ist doch dazu da Fragen zu stellen, über gewisse Sachen zu diskutieren und Lösungen für Probleme/Aufgaben zu finden.

Eine einfache Erklärung das es aus .... Gründen geht und es besser ist diesen Fehlerfall über einen automatischen Service Restart abzufangen hätte auch gereicht.

außer dir niemand Bedarf zu haben scheint.

Es wird (zum Glück) immer mal neue Problemstellungen geben für welche es gilt Lösungsansätze zu finden.

Lg,
Crispyduck

[betateilchen]

Es wird (zum Glück) immer mal neue Problemstellungen geben für welche es gilt Lösungsansätze zu finden.

klar, und für echte "Probleme" werde ich auch immer gerne eine Lösung schaffen. Aber hier gibt es kein Problem.

[Benni]

Muss ich nochmal erwähnen was alternativ passiert?

Nein! Aber a) ist ein gezieltes Beenden hier durchaus sinnvoll, denn b) funktioniert ein blockiertes System eben auch nicht mehr.

Ich habe auch schon erwähnt das ich mein System absichtlich so eingerichtet habe.

Dann ist doch alles gut, aber dann muss doch auch niemand sonst das Problem lösen, dass du dir absichtlich einhandelst.

Verstehe das Problem nicht. Das Forum ist doch dazu da Fragen zu stellen, über gewisse Sachen zu diskutieren und Lösungen für Probleme/Aufgaben zu finden.

Genau! Aber evtl. gibt es mehr als nur eine Lösung für ein Problem. Habe dir eben vorhin eine genannt und nur weil du was absichtlich so eingerichtet hast, wie du es getan hast muss es noch lange nicht gut sein für den Fall, denn offensichtlich hast du dir damit ja ein Problem geschaffen.

Es wird (zum Glück) immer mal neue Problemstellungen geben für welche es gilt Lösungsansätze zu finden.

dito!
Hier gibt es in Wirklichkeit aber kein Problem, zumindest nicht mit ConfigDB!

Und damit bin ich hier raus!

[crispyduck]

Wenn es nicht anders geht ist die Lösung für das Problem ja die Anleitung von betateilchen wie man FHEM als Service inkl. automatischen restart laufen lassen kann.

Warum eine andere Lösung, so wie ich mir gedacht habe das es vielleicht geht, wohl nicht gut ist hat mir ja jetzt auch amenomade erklärt.

Wie gesagt ist die DB auch so gut wie immer erreichbar, sollte diese aber warum auch immer mal nicht da sein, ist es schön wenn sich FHEM zumindest selbst heilt/wieder startet ohne sich extra mit SSH drauf verbinden zu müssen, oder sonst wie agieren zu müssen.

DB am selben Host schließt zwar eine Netzwerkunterbrechung aus, heißt aber auch nicht das diese immer verfügbar ist. Es gäbe auch sonst genügend Möglichkeiten das ganze ausfallsicherer zu machen (redundantes Netzwerk, HA Cluster,....), aber das war ja auch nicht das Problem, sondern das FHEM abstürzt wenn diese nicht verfügbar ist.

Lg,
Crispyduck