Device-State nach Absturz Service

[streetworker]

Hallo zusammen,

meine FHEM-Installation mit RaspPi und HMLan-Adapter läuft tagelang völlig
problemlos um dann immer wieder mal aus heiterem Himmel abzustürzen.

Code Auswählen Erweitern

$Id: fhem.pl 5602 2014-04-22 19:11:59Z rudolfkoenig $

Im Logfile (loglevel 3) findet sich i.d.R. überhaupt kein Hinweis auf das Problem.
Ein einziges Mal hat sich openweathermap als Schuldiger geoutet:

Code Auswählen Erweitern

55 File does not exist: null
56  at ./FHEM/98_openweathermap.pm line 424

Die Abstürze sind unschön, aber mit einem Monitorscript wird der Service
per Cron gleich wieder gestartet.
Wirklich unschön ist aber, das die Devices nach dem Neustart einen mehr oder
weniger zufälligen Status vom letzten Save haben
(Geschlossene Fenster sind scheinbar offen, etc.)
Besonders ärgerlich war, dass der Anwesenheitsstatus dadurch bei Abwesenheit
mehrfach auf anwesend zurückgesetzt wurde.

Letzteres habe ich jetzt erstmal damit entschärft, dass ich beim Ändern des
Anwesenheitsstatus jetzt immer das Statefile sichere:

Code Auswählen Erweitern

fhem("save /dev/null");

Gibt es keine bessere Lösung für dieses Problem? Wie macht ihr das?

//sw





 

[betateilchen]

Dir ist schon klar, dass Du nicht nur das Statefile sicherst, sondern jedesmal die gesamte fhem-Konfiguration?

Ich würde dafür sorgen, dass die Systemstabilität erhöht wird und damit die Ursache verschwindet. Das ist immer besser, als die Symptome zu behandeln.

[streetworker]

Dir ist schon klar, dass Du nicht nur das Statefile sicherst, sondern jedesmal die gesamte fhem-Konfiguration?

Nein, das ist mir nicht klar. Das /dev/null sorgt dafür, dass die Konfiguration in den Orkus geht.
Und einen Weg, nur das Statefile zu sichern, habe ich nicht gefunden.

Ich würde dafür sorgen, dass die Systemstabilität erhöht wird und damit die Ursache verschwindet. Das ist immer besser, als die Symptome zu behandeln.

Würde ich ja liebend gerne. Wenn ich denn einen Hinweis auf das Problem hätte.

Abgesehen davon, werde ich wohl nicht umhin können, zumindest beim Anwesenheitsstatus
immer für einen definierten Zustand zu sorgen.
Eine Alarmanlage, die nach einem Neustart vielleicht eingeschaltet ist, vielleicht aber auch nicht,
ist ja eher ein Witz.

[marvin78]

Beispielsweise

Code Auswählen Erweitern

define atStateFile at +*01:00:00 {WriteStatefile}

sichert das Statefile alle 60 Minuten

[betateilchen]

Und einen Weg, nur das Statefile zu sichern, habe ich nicht gefunden.

Zu wenig gesucht

Code Auswählen Erweitern

{WriteStatefile}

Würde ich ja liebend gerne. Wenn ich denn einen Hinweis auf das Problem hätte.

Dein Problem hast Du hier schon genau beschrieben:

meine FHEM-Installation mit RaspPi

und da sind meist eine ungeeignete Spannungsversorgung und/oder Kontaktprobleme an der SD-Karte (oder die Karte selbst!) die Ursache.

Eine Alarmanlage, die nach einem Neustart vielleicht eingeschaltet ist, vielleicht aber auch nicht,

Eine Alarmanlage, auf die man sich verlassen können möchte, baut man nicht mit fhem.

[streetworker]

Beispielsweise

Code Auswählen Erweitern

define atStateFile at +*01:00:00 {WriteStatefile}

sichert das Statefile alle 60 Minuten

Sehr schön. Danke für den Tipp.

und da sind meist eine ungeeignete Spannungsversorgung und/oder Kontaktprobleme an der SD-Karte (oder die Karte selbst!) die Ursache.

Der Raspberry hat eine Uptime von mehreren Monaten. Andere Serverdienste laufen
problemlos. Das ausgerechnet der FHEM-Prozess sich an "ungeeigneter Spannungsversorgung"
und "Kontaktproblemen der SD-Karte" stört, kann man glauben, muss man aber nicht.

[stromer-12]

Kontaktprobleme mit dem RPi hatte ich diese Tage auch, nach einen Reboot startete er nicht mehr.
Das System läuft bei mir im normalen Betrieb von einer SSD und da waren mir das Problem mit der
SD-Karte nicht aufgefallen. Meine Karte hatte schwierigkeiten auf den mittleren Anschlußflächen,
sie sich gebogen hatte.

[Puschel74]

Hallo,

das

Der Raspberry hat eine Uptime von mehreren Monaten.

und das

meine FHEM-Installation mit RaspPi und HMLan-Adapter läuft tagelang völlig
problemlos um dann immer wieder mal aus heiterem Himmel abzustürzen.

passt aber irgendwie nicht zusammen.

Wenn der RasPi aus heiterem Himmel abstürzt - wie kommst du dann auf eine Uptime von mehreren Monaten?

Das ausgerechnet der FHEM-Prozess sich an "ungeeigneter Spannungsversorgung"
und "Kontaktproblemen der SD-Karte" stört, kann man glauben, muss man aber nicht.

Das ist richtig - kann man, muss man aber nicht.

Wenn ein Fass voll ist genügt ein Tropfen damit es überläuft 
Ein Service mehr oder ein zusätzlicher Dienst und es kann ausreichend sein das der RasPi Probleme bekommt - mit der Spannungsversorgung.
Kannst du jetzt glauben - musst du aber nicht 

Da aber auch nur du deine Installation kennst kannst auch nur du das überprüfen.

Es wurde ja schon geschrieben:

Ich würde dafür sorgen, dass die Systemstabilität erhöht wird und damit die Ursache verschwindet. Das ist immer besser, als die Symptome zu behandeln.

Grüße

[streetworker]

Wenn der RasPi aus heiterem Himmel abstürzt - wie kommst du dann auf eine Uptime von mehreren Monaten?

Ich dachte, ich hätte schon im ersten Post geschrieben, dass der FHEM-Service
per Cronjob nach Abstürzen automatisch neu gestartet wird.
Der Raspberry und Debian laufen wie ein Uhrwerk.

[Puschel74]

Hallo,

nö, also nicht so direkt.

meine FHEM-Installation mit RaspPi und HMLan-Adapter läuft tagelang völlig
problemlos um dann immer wieder mal aus heiterem Himmel abzustürzen.

Hier ging ich davon aus das dein RasPi abstürzt.

dass der FHEM-Serviceper Cronjob nach Abstürzen automatisch neu gestartet wird.

Ok, also das:

aber mit einem Monitorscript wird der Service per Cron gleich wieder gestartet.

Was aber nichts dran ändert die Ursache zu suchen.

Da ich auch einen RasPi mit HM-Lan-Adapter und FS20-Geräten benutze hier mal meine uptime

upTime   : 4 days, 09:21:20

Und vor 4 Tagen habe ich bewusst einen reboot gemacht.

Grüße