Regeln beim Start nicht gefunden

[kkreuzer]

Guter Hinweis, danke. Werde ich bei Gelegenheit mal versuchen zu reproduzieren...

[theneon]

Ich konnte das Problem mittlerweile bei mir lösen. Es lag an den Rules mit "System started"-Trigger. Entferne ich den Trigger aus den Rules, werden alle Dateien richtig gelesen und gestartet.
Der "System started"-Trigger wird wohl gesetzt, bevor alle Rule-Files geladen worden sind und führt somit die betroffenen Regeln aus. Warum dies zu dem Fehler führt ist mir noch nicht klar.

Bei mir war es das gleiche Problem ....

[Jockel]

Wobei es ganz so einfach nicht zu sein scheint. Ich hab hier auch einige Regeln mit "System started" trigger, meist werden die Dateien beim Start problemlos gelesen, aber eben nicht immer.

Bei einem erneuten Start ist es dann meistens OK.

Letztens hatte ich einen hartnäckigen Fall, da vermute ich einen Fehler in einer anderen Rules-Datei als Ursache, zumindest klappte wieder alles als der beseitigt war.

[boxerfahrer]

Ich kann vom gleichen Problem mit openhab 1.3.1. auf einem pi berichten. Es sind bei mir offensichtlich alle Regeln mit "System started" trigger betroffen. Speichere ich die betroffenen Dateien einige Minuten nach dem Start von openhab nochmal neu, wird der jeweilige "System started" trigger aufgerufen, und ab da "funktionierts" für diese Datei.

[multimedia]

Hallo,

habe ebenfalls dieses Problem, bei Vers. 1.3.1, auf einem pi, Regeln werden sporadisch nicht bei jedem Start von openhab ausgeführt.
Es hat bei mir auch nichts mit dem "System started" Trigger zu tun. Den habe ich in den Regeln gar nicht verwendet.
Nachdem Regeln nach meiner Auffassung callback Funktionen sind, die bei Auftreten eines Ereignisses aufgerufen werden, verstehe ich auch nicht, warum die Zeiten in der openhab.cfg hier einen Einfluss haben sollten. Wenn es tatsächlich die Zeit bis zum nächsten Scan ist, die hier eingestellt wird, sollte die Datei mit den Regeln doch zumindest beim nächsten Scan wieder aktiviert worden sein.
Sehr merkwürdig...

[multimedia]

... hab die letzten Stunden noch ein wenig weiter getestet.
Ich kann jetzt reproduzieren, wann die Regeln beim Neustart nicht (immer) eingelesen werden. Es ist dann, wenn der pi nicht korrekt runtergefahren wurde, also speziell dann, wenn ihm einfach die Spannungsversorgung genommen wird.
Im Fehlerfall kommt dann bei Hochfahren von openhab die Warnung:

... GenericItemProvider[:129] - Attempting to register a second BindingConfigReader of type 'autoupdate'. The primary reader will remain active!

Eine USV wird man sich wegen dem pi nun nicht anschaffen.
Hat jemand eine Idee was man hier machen könnte?

Liebe Grüsse
Christian

[Jockel]

Ich glaube nicht, dass das die Ursache ist, zumindest nicht die einzige. Mein Server läuft hier wochenlang durch und trotzdem habe ich bei manchen Starts von openHAB das Problem.

In Deinem speziellen Fall fällt mir nichts ein außer eben ordentlich herunterzufahren oder die Regeln auf einem ro gemounteten Filesystem zu haben.

[multimedia]

Hallo Jockel,

vielen Dank für Deine Antwort.
Wie beendest du denn openhab?
Kannst du ebenfalls im Fehlerfall nach dem Hochlauf die Warnmeldung feststellen?
Vielleicht kann einer unserer groovies über diese Meldung beurteilen, was die Fehlerursache sein könnte...

Thanx
Christian

[Jockel]

Wie beendest du denn openhab?

Ich hab openHAB als Dämon auf dem Mac laufen und beende es mit launchctl unload, das führt wohl einen "sanften" kill aus.

Kannst du ebenfalls im Fehlerfall nach dem Hochlauf die Warnmeldung feststellen?

Bei mir tritt der Fehler auch auf wenn openHAB sauber beendet wurde, wovon es abhängt kann ich aber nicht sagen. Manchmal klappt es beim ersten Startversuch, manchmal braucht es 2 oder 3 bis alles OK ist. Den Rechner selbst fahr ich quasi nie runter.

[udo1toni]

Auch bei mir werden ab und zu einzelne Rule-Files während des Starts nicht korrekt geladen. Wenn ich die Files dann ändere, greift die autoload-Funktion. Schick wäre, wenn openHAB bei solchen Files nach einigen Sekunden einen weiteren Versuch unternähme, das File zu lesen. Die Fehlermeldung bei mir legt nahe, dass es einen Zugriffsfehler auf Dateisystemebene (bzw. im entsprechenden java-modul) gibt:

18:04:17.839 ERROR o.e.x.r.i.DefaultResourceDescription[:75]- tore.rules (Datei oder Verzeichnis nicht gefunden)
java.io.FileNotFoundException: tore.rules (Datei oder Verzeichnis nicht gefunden)
18:04:17.839 INFO  o.o.m.c.i.ModelRepositoryImpl[:79]- Loading model 'tore.rules'
18:04:17.840 WARN  o.o.m.c.i.ModelRepositoryImpl[:58]- Configuration model 'tore.rules' is either empty or cannot be parsed correctly!

was natürlich bullshit ist - schließlich hat er den Dateinamen vorher erfolgreich ermittelt...
Natürlich wäre das nur Behandlung der Symptome, sorgt aber vielleicht für einen stabileren Start.
Ach ja: openHAB 1.4.0#558, in einer 64bit-Debian-wheezy-DomU mit oracle-jre 1.7.0_45-b18, der Fehler tritt aber schon seit längerem auf.

[kkreuzer]

Hier haben wir übrigens auch ein Issue für das Phänomen: https://github.com/openhab/openhab/issues/736

Grüße,
Kai

[multimedia]

Das Problem hat sich bei mir (openHAB auf Raspi) nach Update auf 1.4 erledigt.
Die Regeln werden jetzt immer korrekt eingelesen.
Auch die Fehlermeldung

... GenericItemProvider[:129] - Attempting to register a second BindingConfigReader of type 'autoupdate'. The primary reader will remain active!

kommt jetzt nicht mehr, selbst nach einem Spannungsausfall.
Vielen Dank!

[Jockel]

Eigentlich war ich davon ausgegangen, dass sich das Problem mit dem Update auf 1.4.0 erledigt hat, leider habe ich es eben aber wieder beobachten können:

2014-02-21 22:06:39.776 ERROR o.e.x.r.i.DefaultResourceDescription[:75]- visu.rules (No such file or directory)
java.io.FileNotFoundException: visu.rules (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:146)
	at org.eclipse.emf.ecore.resource.impl.FileURIHandlerImpl.createInputStream(FileURIHandlerImpl.java:99)
	at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:354)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1256)

[NSchnitzler]

Guten Abend,

ich wollte das Thema noch mal aufgreifen, auf meinem Pi mit der 1.5er Version von Montag habe ich immer das Problem, dass alle Möglichen Dateien nicht gefunden werden und der rrd Dienst nicht mehr richtig geht. Hier ist mal ein Ausschnitt aus dem Debug Protokoll:

23:45:10.868 ERROR o.e.x.r.i.DefaultResourceDescription[:75] - rrd4j.persist (Datei oder Verzeichnis nicht gefunden)
java.io.FileNotFoundException: rrd4j.persist (Datei oder Verzeichnis nicht gefunden)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:146)
	at org.eclipse.emf.ecore.resource.impl.FileURIHandlerImpl.createInputStream(FileURIHandlerImpl.java:99)
	at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:354)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1256)
	at org.eclipse.xtext.resource.impl.DefaultResourceDescription.computeExportedObjects(DefaultResourceDescription.java:73)
	at org.eclipse.xtext.resource.impl.DefaultResourceDescription$4.get(DefaultResourceDescription.java:172)
	at org.eclipse.xtext.resource.impl.DefaultResourceDescription$4.get(DefaultResourceDescription.java:1)
	at org.eclipse.xtext.util.OnChangeEvictingCache.get(OnChangeEvictingCache.java:75)
	at org.eclipse.xtext.resource.impl.DefaultResourceDescription.getLookUp(DefaultResourceDescription.java:167)
	at org.eclipse.xtext.resource.impl.AbstractResourceDescription.getExportedObjects(AbstractResourceDescription.java:44)

andere Regeln und Scripte werden auch nicht gefunden, das tauchen der rrd4j-Datei hilft übrigens nicht.

Hat jemand eine Idee, ganz ohne persistence macht das irgendwie keinen Spass.

Gruss und Danke

Norbert

[NSchnitzler]

noch ein Nachtrag dazu, das rrdtool sagt, es würde sich nicht um rrd Dateien handeln, hat jemand eine Idee dazu?

Gruss und schöne Ostertage!

Norbert