OpenEms am Raspberry konfigurieren

Hallo zusammen,
Ich würde gerne das OpenEms am Raspberry installieren.
Nun habe ich die Anleitung schrittweise befolgt, bekomme aber nun folgende Fehlermeldung.

Mai 23 15:36:51 raspberrypi systemd[1]: openems.service holdoff time over, scheduling restart.
Mai 23 15:36:51 raspberrypi systemd[1]: Stopping OpenEMS…
Mai 23 15:36:51 raspberrypi systemd[1]: Starting OpenEMS…
Mai 23 15:36:51 raspberrypi systemd[1]: openems.service: main process exited, code=exited, status=203/EXEC
Mai 23 15:36:51 raspberrypi systemd[1]: Failed to start OpenEMS.
Mai 23 15:36:51 raspberrypi systemd[1]: Unit openems.service entered failed state.

Dabei ist mir aufgefallen, dass in openems.service zum Ausführen von Ems folgendes Directory benutzt wird:

/usr/lib/jvm/java-8-openjdk-armhf/bin/java

Der Unterordner /usr/lib/jvm ist nicht existent auf meinem Raspberry.
Java ist aber installiert auf meinem Raspberry, wie folgende Ausgabe zeigt:

java version “1.8.0_65”
Java™ SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot™ Client VM (build 25.65-b01, mixed mode)

Ich konnte den Fehler durch die Installation von Java im oben genannten Pfad beheben.

Hallo,

der “längere” Pfad hat eher historische Gründe (auf Debian Jessie wird OpenJDK 8 in diesem Unterordner installiert). Der reguläre Pfad für die Java runtime ist /usr/bin/java. Diesen Pfad findet man übrigens mit dem Befehl which java in der Konsole.

Ich habe die Doku angepasst und den regulären Pfad eingesetzt. Danke für den Hinweis.

Gruß,
Stefan

Hallo,

Wenn ich versuche OpenEms.jar mit

systemctl restart openems --no-block; journalctl -lfu openems

zu starten, erhalte ich folgende Fehlermeldung:

Failed to restart openems.service: Activation of org.freedesktop.systemd1 timed out
– Logs begin at Mo 2019-05-27 17:17:01 CEST. –
Mai 28 17:17:13 raspberrypi java[8686]: at io.openems.edge.core.cycle.Cycle.forever(Cycle.java:91)
Mai 28 17:17:13 raspberrypi java[8686]: at io.openems.common.worker.AbstractWorker$1.run(AbstractWorker.ja va:112)
Mai 28 17:18:13 raspberrypi java[8686]: 2019-05-28 17:18:13,813 [Executor] ERROR [s.common.worker.Abstract Worker] Worker error. LastErrorException: [107] Der Socket ist nicht verbunden
Mai 28 17:18:13 raspberrypi java[8686]: com.sun.jna.LastErrorException: [107] Der Socket ist nicht verbund en
Mai 28 17:18:13 raspberrypi java[8686]: at info.faljse.SDNotify.jna.CLibrary.send(Native Method)
Mai 28 17:18:13 raspberrypi java[8686]: at info.faljse.SDNotify.io.NativeDomainSocket.send(NativeDomainSoc ket.java:58)
Mai 28 17:18:13 raspberrypi java[8686]: at info.faljse.SDNotify.SDNotify.sendString(SDNotify.java:193)
Mai 28 17:18:13 raspberrypi java[8686]: at info.faljse.SDNotify.SDNotify.sendWatchdog(SDNotify.java:142)
Mai 28 17:18:13 raspberrypi java[8686]: at io.openems.edge.core.cycle.Cycle.forever(Cycle.java:91)
Mai 28 17:18:13 raspberrypi java[8686]: at io.openems.common.worker.AbstractWorker$1.run(AbstractWorker.ja va:112)

Lg,
Dominik

Hallo Dominik,

das klingt nach einem Problem mit dem Systemd Watchdog. OpenEMS Edge nutzt die Bibliothek SDNotify, um Systemd mitzuteilen, dass es erfolgreich gestartet wurde (“ready”) und stabil läuft (“watchdog”).

Den Fehler hatte ich noch nie. Es sollte aber reichen, hier mit einem try-catch die “com.sun.jna.LastErrorException” abzufangen. Wenn du das gemacht hast und es klappt, würde ich mich über einen Pull-Request freuen.

Wie sieht denn deine systemd service-definition aus? (vgl. Doku)

Gruß,
Stefan

Hallo Stefan,

Weder die Abfrage “SDNotify.isAvailable();” noch der Funktionsaufruf “SDNotify.sendWatchdog();” werfen eine Exception.
Jedoch erkennt der Compiler die Klasse “LastErrorException” nicht, sodass ich
die Standard Exceptionklasse verwendet habe.
Selbst wenn ich “SDNotify.sendWatchdog();” ohne vorherige Abfrage aufrufe,
bekomme ich dieselben Fehlermeldungen, wie oben beschrieben.

Meine systemd sieht wie folgt aus:

[Unit]
Description=OpenEMS
After=network.target

[Service]
User=root
Group=root
Type=notify
WorkingDirectory=/usr/lib/openems
LimitCORE=infinity
LimitRTPRIO=2
LimitRTTIME=60000000
CPUSchedulingPolicy=rr
CPUSchedulingPriority=1
ExecStart=/usr/bin/java -Dfelix.cm.dir=/etc/openems.d/ -jar /usr/lib/openems/openems.jar
SuccessExitStatus=143
Restart=always
RestartSec=10
WatchdogSec=60

[Install]
WantedBy=multi-user.target

Grüße,
Dominik

Hallo Dominik,

ok, das sieht alles gut aus. Stimmt, die “com.sun.jna.LastErrorException” ist nicht verfügbar, weil dafür erst das Paket “com.sun.jna” importiert werden müsste. Abfangen der normalen “Exception” ist aber in dem Fall auch ok und fängt auch mögliche andere, nicht-kritische Fehler ab. Den “catch”-Block kannst du von mir aus sogar leer lassen.

Funktioniert es denn jetzt, wenn du die Exception abfängst? Dann würde ich das gerne in den develop-Brach mit aufnehmen.

Gruß,
Stefan

Hallo Stefan,
Wenn ich im Catch-Block eine Warnmeldung mit “log.warn” implementiere,
müsste ja bei einer abgefangenen Exception die Meldung ausgegeben werden.
Da dies nicht der Fall ist, denke ich, dass durch “SDNotify” keine Exception ausgelöst wird.

Der system log gibt diesselben Fehlermeldungen aus wie unter #3:

Grüße,
Dominik

Hallo Stefan,
Ich habe in der “systemd” Zeile 15 wieder auf

ExecStart=/usr/lib/jvm/java-8-openjdk-armhf/bin/java -Dfelix.cm.dir=/etc/openems.d/ -jar /usr/lib/openems/openems.jar

geändert.
Nun funktioniert alles problemlos, auch ohne Abfangen der Exception.

Grüße,
Dominik

Dann muss es an der Java runtime liegen. Welche Version hat denn /usr/bin/java?

/usr/bin/java -version

java version “1.8.0_65”
Java™ SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot™ Client VM (build 25.65-b01, mixed mode)

Nein, das würde auch passen. Eine andere Idee habe ich momentan auch nicht. Aber gut, wenn es jetzt funktioniert, würde ich es dabei belassen.