"Endlosschleife" bei Raspberry Pi 2 und at +* Kommando nach Neustart

Begonnen von couchtomato, 04 November 2018, 20:10:33

Vorheriges Thema - Nächstes Thema

couchtomato

Hallo zusammen,

ich habe meinen Raspberry Pi 2 frisch aufgesetzt auf Basis von dem aktuellen Raspbian Stretch Lite Image 2018-10-09 und per apt gemäß Anleitung installiertem FHEM. Hardwareseitig habe ich eine HM-MOD-RPI-PCB eingebaut und steuere damit in meinem Test-Setup ein Homematic Heizungsthermostat HM-CC-RT-DN an. Soweit ein unspektakuläres Setup.

Nun habe ich folgendes merkwürdige Problem nach jedem Reboot: Sobald ich in meiner fhem.cfg eine Aktion definiere, die regelmäßíg ausgeführt werden soll, z. B. 1 x pro Minute, gerät mein Raspberry nach jedem Neustart in eine Endlosschleife, die sich mit 100% CPU Last (gemäß top-Befehl) im perl Prozess sowie einem vollaufenden FHEM-Logfile äußert. Auch das Webinterface von FHEM kann ich nun nicht mehr erreichen. Es spielt hierbei keine Rolle, ob ich definiere dass die Aktion jede Minute, alle 10 Minuten oder alle 15 Minuten ausgeführt wird. Auch die Art der Aktion scheint irrelevant zu sein, es reicht bereits ein Log-Eintrag.

Hier ist mein Demo-Befehl. Jede Minute soll ein Log-Eintrag geschrieben werden - soweit so simpel:
define JedeMinute at +*00:01:00 { Log 1, "Eine Minute rum." }


Ist das so syntaktisch richtig?

Wenn ich während FHEM läuft diesen Eintrag in meine fhem.cfg eintrage und speichere, läuft auch FHEM brav weiter und es wird erwartungsgemäß jede Minute ein Logeintrag geschrieben. Starte ich nun jedoch meinen Raspberry Pi neu (wohlgemerkt Reboot, nicht nur Service-Neustart), führt FHEM nicht nur einmalig pro Minute, sondern ununterbrochen dieses Kommando (Loggen) aus und schreibt das Logfile voll mit nicht mehr endenden Logeinträgen "Eine Minute rum." und es kommt zu der beschriebenen 100% CPU Last. Immerhin gelingt nach geduldigem Warten noch ein Beenden des FHEM Services (sudo service fhem stop), so dass man dann etwa das bis dato geschriebene Logfile sichten kann.

Das Problem tritt hingegen definitiv nicht auf, sofern sich die oben genannte Zeile nicht in meiner fhem.cfg befindet.

Nachdem ich mich hier durch noch andere Forenbeiträge gewühlt habe, habe ich herausgefunden, dass in solchen Situationen möglicherweise ein verzögerter Start von FHEM Abhilfe schaffen kann. Hierzu habe ich meine /etc/systemd/system/fhem.service um den folgenden Eintrag ergänzt
ExecStartPre=/bin/sleep 10

Dies funktioniert offenbar auch. Dennoch ist meine Verwunderung groß, warum es überhaupt zu dem beschriebenen Problem kommt und ob mein Workaround überhaupt "gut" ist. Ich weiß z. B. nicht ob es 5, 10 oder 15 sec sein sollten.

Was ist Eure Meinung dazu?

Anbei meine FHEM Systeminfo:
System Info
ConfigType: configFile
SVN rev: 17629
OS: linux
Perl: 5.24.1
uniqueId: 089...

Modules Model Count
CUL_HM 8
HM-CC-RT-DN 1
ActionDetector 1
FHEMWEB 3
FileLog 2
HMUARTLGW
HM-MOD-UART 1
SVG 2
at 7
autocreate 1
dummy 6
eventTypes 1
notify 7
weblink
I ♥ FHEM.
(FHEM@ 2 x RPi1, 1 x RPi2, 1x RPi3).

Beta-User

"Verpasste at's" werden "nachgeholt!
Es gibt set einiger Zeit ein Attribut um das zu verhindern, bitte commandref konsultieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

couchtomato

#2
Danke für den Tipp! Hmm, ich habe in der CommandRef nachgelesen ... vielleicht habe ich da Tomaten vor den Augen.  ;) Meinst Du evtl., dass ich
attr JedeMinute computeAfterInit 1
setzen müsste (gemäß https://fhem.de/commandref_DE.html#at bzw. https://forum.fhem.de/index.php?topic=56706.0 )?
Das habe ich ausprobiert, hilft jedoch leider nicht. Auch die anderen Attribute erscheinen mir da jetzt nicht wirklich so hilfreich.
Allerdings gefällt mir der Ansatzpunkt, dass es vielleicht irgendetwas mit der Uhrzeit zu tun haben könnte (der Pi setzt sich ja erst per NTP die Uhrzeit und vielleicht ist der FHEM Service Start irgendwie zu einem ungünstigen Zeitpunkt).
I ♥ FHEM.
(FHEM@ 2 x RPi1, 1 x RPi2, 1x RPi3).

Beta-User

Hmmm, an diesen thread hatte ich eigentlich gedacht. Das scheint aber nur zu klappen, wenn timespec Perlcode ist, also gerade keine fixe Zeitangabe enthält.
Workaround z.B.: notify auf global-initialized und darin das at (mit Option temporary) definieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

couchtomato

Der notify auf global-initialized (mit temporary) führt leider ebenfalls zur "Endlosschleife".  :(

Setze ich statt "at" "DOIF" ein, funktioniert es jedoch, wie ich gerade herausgefunden habe:
define JedeMinute2 DOIF {if ([+:01]) { Log 1, "Eine Minute rum." } }

Das wäre für mich so mal in Ordnung. Trotzdem ein wenig komisch, warum es sich bei dem "at" so verhält.
I ♥ FHEM.
(FHEM@ 2 x RPi1, 1 x RPi2, 1x RPi3).

Beta-User

Dürfte an der fehlenden RTC bzw. dem Start von fhem vor Netzwerkverfügbarkeit liegen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Das Problem ist das bis kurz nach dem Start die Uhrzeit auf 01.01.1970 steht und fhem damit startet. Dann werden alle at Zeiten seit dem ausgeführt.

Gib dem Linux mal einen Zeitserver.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

couchtomato

Ja, das war genau die Ursache. Danke an CoolTux und Beta-User!
Ich habe nun sichergestellt, dass FHEM erst ganz am Schluss gestartet wird, nachdem die Zeit vom NTP-Server geholt wurde gestartet wird. Und siehe da - nun klappt auch das at +* ohne Endlosschleife.  :)

Das ganze war leider mit systemd etwas kompliziert, da multi-user.target bisher der letzte durchlaufene Target war und sowohl dem NTP Dämon wie auch dem FHEM Service zu Grunde liegt. Es ist dann reine Glückssache in welcher Reihenfolge was gestartet wird.

Daher bin ich wie folgt vorgegangen. Erstmal Superuser-Rechte beschaffen: sudo su

Ich habe ein neues custom.target angelegt: nano /etc/systemd/system/custom.target

[Unit]
Description=Target for services that should start at the end, e. g. after time is set by ntp server.
Requires=multi-user.target
After=multi-user.target
AllowIsolate=yes


Dieses habe ich dann als default-target gesetzt: systemctl set-default custom.target 

Anschließend habe ich das systemd-Skript /etc/systemd/system/fhem.service folgendermaßen angepasst :
# $Id: fhem.service 16001 2018-01-26 11:54:41Z betateilchen $

[Unit]
Description=FHEM Home Automation
After=multi-user.target

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always

[Install]
WantedBy=custom.target


Anschließend habe ich einen Ordner /etc/systemd/system/custom.target.wants angelegt und dort einen symbolischen Link auf fhem.service gesetzt:

mkdir /etc/systemd/system/custom.target.wants
ln -s /etc/systemd/system/fhem.service /etc/systemd/system/custom.target.wants/fhem.service


Nun habe ich das System neugestartet:
reboot

Voilla, nun startet FHEM erst ganz am Schluss (was natürlich etwas länger braucht als vorher), aber dafür ist man endlosschleifenfrei.  ;)
Ich weiß nicht genau, ob es vielleicht noch einen anderen Weg als den mit dem custom.target gibt. Jedenfalls klappt das so ganz gut bei mir.
I ♥ FHEM.
(FHEM@ 2 x RPi1, 1 x RPi2, 1x RPi3).

Beta-User

Klar gibt es einen anderen Weg: installiere eine RTC.
Eigentlich ist es ein Unding, dass die pi-foundation alle möglichen Schnittstellen einbaut, aber sowas wichtiges nicht...

Bleibt das eben ein Punkt für anti-pi-Werbung...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files