Ich bin mir nicht bewußt, dass ich wesentliche Änderungen am System vorgenommen hätte, ausser ein paar überflüssige HMdevices zu löschen, aber seit ein paar Tagen hab ich nur noch die folgenden Zeilen in Endlosschleife (alle 10s) im LogFile:
2022.10.10 16:43:34 2: eventTypes: loaded 1440 lines from ./log/eventTypes.txt
2022.10.10 16:43:35 1: HMCCU [myCCU3] CCU port 48181 is reachable
2022.10.10 16:43:35 1: HMCCU [myCCU3] Initialized version 5.0 220431743
2022.10.10 16:43:35 1: HMCCU [myCCU3] Initializing device
2022.10.10 16:43:36 2: HMCCU [myCCU3] Deleting old CCU configuration data
2022.10.10 16:43:36 2: HMCCU [myCCU3] Updating device table
2022.10.10 16:43:36 1: HMCCU [myCCU3] Read 38 devices with 321 channels from CCU 192.168.2.60
2022.10.10 16:43:36 1: HMCCU [myCCU3] Read 10 programs from CCU 192.168.2.60
2022.10.10 16:43:36 1: HMCCU [myCCU3] Read 8 virtual groups from CCU 192.168.2.60
2022.10.10 16:43:36 1: PERL WARNING: Argument "str*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 664.
2022.10.10 16:43:37 1: Watchdog Client: systemd watchdog is not available. Module inactive.
2022.10.10 16:43:40 2: HMCCURPCPROC [d_rpc002060VirtualDevices] CCU interface VirtualDevices doesn't support RPC multicalls
2022.10.10 16:43:40 1: HMCCURPCPROC [d_rpc002060VirtualDevices] Initialized version 5.0 220431743 for interface VirtualDevices with I/O device myCCU3
2022.10.10 16:43:40 2: HMCCURPCPROC [d_rpc002060BidCos_RF] CCU interface BidCos-RF supports RPC multicalls
2022.10.10 16:43:40 1: HMCCURPCPROC [d_rpc002060BidCos_RF] Initialized version 5.0 220431743 for interface BidCos-RF with I/O device myCCU3
2022.10.10 16:43:40 2: HMCCURPCPROC [d_rpc002060HmIP_RF] CCU interface HmIP-RF doesn't support RPC multicalls
2022.10.10 16:43:40 1: HMCCURPCPROC [d_rpc002060HmIP_RF] Initialized version 5.0 220431743 for interface HmIP-RF with I/O device myCCU3
2022.10.10 16:43:40 2: ONKYO_AVR PioneerVSX1131: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
/var/run/fhem/fhem.pid: No such file or directory
Wie fange ich mit der Fehlersuche an. Die Installation läuft mit configDB.
Fhem ist nicht zu erreichen, die piccu läuft fehlerfrei.
Hilfe!
Was ist es für eine Platform, auf dem FHEM läuft?
ein Raspi 3 , mit RPI-RF-MOD, bullseye.
Weißt du zufällig, wie deine systemd_watchdog-Instanz heißt?
Dann deaktiviere die mal beim Start: https://forum.fhem.de/index.php/topic,86225.msg1236573.html#msg1236573
Wenn du den Namen nicht kennst, benennst du die Datei im Modulverzeichnis einfach mal um.
Habe die systemd-watchdog.pm mal unbenannt. Keine Auswirkung, ausser dass der entsprechende LogEintrag weg ist.
Ein Rescue-Start mit rescue => "1" in der configDB.config bringt nach dem Neustart das:
2022.10.10 18:02:14 0: configDB starting in rescue mode!
2022.10.10 18:02:14 3: telnetPort: port 7072 opened
2022.10.10 18:02:14 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
2022.10.10 18:02:15 0: configDB starting in rescue mode!
2022.10.10 18:02:15 3: telnetPort: port 7072 opened
2022.10.10 18:02:16 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
2022.10.10 18:02:56 0: configDB starting in rescue mode!
2022.10.10 18:02:56 3: telnetPort: port 7072 opened
2022.10.10 18:02:56 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
2022.10.10 18:02:57 0: configDB starting in rescue mode!
2022.10.10 18:02:58 3: telnetPort: port 7072 opened
2022.10.10 18:02:58 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
2022.10.10 18:02:59 0: configDB starting in rescue mode!
2022.10.10 18:02:59 3: telnetPort: port 7072 opened
2022.10.10 18:02:59 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
2022.10.10 18:03:01 0: configDB starting in rescue mode!
2022.10.10 18:03:01 3: telnetPort: port 7072 opened
2022.10.10 18:03:01 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
2022.10.10 18:03:02 0: configDB starting in rescue mode!
2022.10.10 18:03:02 3: telnetPort: port 7072 opened
2022.10.10 18:03:03 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
Hast du evtl. den systemd-timeout geändert?
Das hätte ich dann in der fhem.service gemacht?
Die sieht so aus:
# $Id: fhem.service 19235 2019-04-21 13:26:17Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service
[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=multi-user.target
Ich hoffe ich stell mich gerade nicht zu dumm an :-( Ich bin immer froh wenn alles läuft, hab aber auch nicht die Zeit mich immer sofort um Fhem zu kümmern, wenns mal nicht läuft. Ist bei mir auch nur ganz oben aufgelegt, so dass auch ohne alles wichtige weiterläuft. Muss mich also ständig wieder neu einarbeiten und zwischendurch vergehen dann mal ein paar Wochen.
Hmm, bin auch nicht sicher, ob das aus systemd kommt, komisch ist auf alle Fälle, dass da jeweils als letztes ein Log-Eintrag drin ist, der mAn. nicht von fhem.pl geschrieben wird. Und das mit der pidfile klingt irgendwie nach systemd.
Könnte auch sein, dass du den globalen default geändert hast:
https://codybonney.com/change-default-timeouts-starting-stopping-systemd-units/
Ansonsten ist in https://www.freedesktop.org/software/systemd/man/systemd.service.html zu finden, dass es eigentlich bei Type=forking empfehlenswert wäre, eine pidfile anzugeben. So tief bin ich da aber auch nicht drin, kann auch sein, dass das ein Holzweg ist...
Was passiert denn, wenn Du FHEM direkt von der Linux Konsole aus manuell startest, anstatt über systemd?
Ein manueller Start mit sudo /opt/fhem/fhem.pl configDB
gibt die Fehlermeldung:
2022.10.10 20:03:12 1: Can't locate configDB.pm in @INC (you may need to install the configDB module) (@INC contains: . /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/aarch64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 10) line 1.
BEGIN failed--compilation aborted at (eval 10) line 1.
Die Installation lief aber bis vor ein paar Tagen problemlos. Kann da durch ein update was zerwürfelt worden sein?
- Du musst vorher in das Verzeichnis /opt/fhem wechseln
- zum Testen solltest Du als root arbeiten, ob das mit sudo funktioniert, weiß ich nicht genau
Start mit root@raspberrypi:/opt/fhem# ./fhem.pl configDB geht ohne Fehlermeldung durch.
Das Log sieht dann wieder so aus
2022.10.10 20:23:12 0: configDB starting in rescue mode!
2022.10.10 20:23:12 3: telnetPort: port 7072 opened
2022.10.10 20:23:13 3: web: port 8083 opened
/var/run/fhem/fhem.pid: No such file or directory
Sieh mal in deiner configDB nach ob da etwas von
attr global pidfilename
drin steht.
Wenn ja. Nimm das mal raus.
:-[ configDB editieren :o
Mit dem Thema hatte ich mich mal vor einiger Zeit rein theoretisch beschäftigt, als ich feststellen musste, dass mein Backup zu alt war. Bin zu dem Schluss gekommen, dass das ausser meiner Reichweite liegt. Oder gibt es da auch einfache Wege?
PS: Bin jetzt bis erstmal in Nachtruhe. Vielen Dank für eure Denkarbeit schonmal.
Nur mal auf die schnelle. was steht denn im PID-Verzeichnis:
sudo ls -lha /var/run/fhem/
Zitat von: VolkerGBenner am 10 Oktober 2022, 20:47:22
Bin zu dem Schluss gekommen, dass das ausser meiner Reichweite liegt. Oder gibt es da auch einfache Wege?
Der Fehler kommt mit ziemlicher Sicherheit nicht aus der configDB.
Im rescue mode hat die Datenbank definitiv kein gesetztes Attribut pidfile.
Es geht darum, herauszufinden, wer oder was überhaupt nach einem pidfile von FHEM sucht.
Hast Du einen hardware-watchdog definiert, der nach einem pidfile sucht?
Zitat von: Wernieman am 10 Oktober 2022, 21:07:09
Nur mal auf die schnelle. was steht denn im PID-Verzeichnis:
sudo ls -lha /var/run/fhem/
Und wo kommt dieses Verzeichnis überhaupt her, wenn es denn existiert?
Zitat von: betateilchen am 10 Oktober 2022, 21:20:52
Hast Du einen hardware-watchdog definiert, der nach einem pidfile sucht?
nicht wissentlich. Welche Hardware würde davon profitieren? Habe ja nur die Funk-Platine auf dem Pi.
Hast Du vor Deinem Versuch mit dem manuellen Start den fhem service komplett beendet - nicht dass da ein automatischer restart dazwischengefunkt hat?
Hast Du schonmal versucht, Dein FHEM mit der demo-Konfiguration zu starten?
# cd /opt/fhem
# perl fhem.pl fhem.cfg.demo
Zitat von: betateilchen am 10 Oktober 2022, 21:28:35
Und wo kommt dieses Verzeichnis überhaupt her, wenn es denn existiert?
Es existierte nicht, bis ich es wegen der Meldung heute Nachmittag mal manuell angelegt habe.
Zitat von: betateilchen am 10 Oktober 2022, 21:34:23
Hast Du vor Deinem Versuch mit dem manuellen Start den fhem service komplett beendet - nicht dass da ein automatischer restart dazwischengefunkt hat?
Hast Du schonmal versucht, Dein FHEM mit der demo-Konfiguration zu starten?
# cd /opt/fhem
# perl fhem.pl fhem.cfg.demo
Der Service war gestoppt mit
sudo service fhem stopDer hat dann auch nicht weiter zu starten versucht. Hatte auch das fhem.log gelöscht. Das wurde dann vom manuellen Start neu angelegt.
Zitat von: betateilchen am 10 Oktober 2022, 21:20:52
Es geht darum, herauszufinden, wer oder was überhaupt nach einem pidfile von FHEM sucht.
Irgendwie klingt es danach, als würde das mit FHEM mit gestartet werden. Könnte auch was aus einer myUtils sein.
Vielleicht fördert das hier im Modul-Verzeichnis irgendwas zutage:
grep -i 'fhem.pid' *
Falls dieses neu angelegte Verzeichnis noch existiert, sollte es m.E. wieder gelöscht werden. Nicht, dass wir jetzt auch noch ein Rechte-Problem kurieren müssen...
Zitat von: betateilchen am 10 Oktober 2022, 21:34:23
Hast Du schonmal versucht, Dein FHEM mit der demo-Konfiguration zu starten?
# cd /opt/fhem
# perl fhem.pl fhem.cfg.demo
Demo läuft.
Dieses komische Verzeichnis ist auch hier genannt:
http://s6z.de/cms/index.php?id=142:fhem-watchdog-mit-systemd (http://s6z.de/cms/index.php?id=142:fhem-watchdog-mit-systemd)
In der überarbeiteten Fassung des Vorschlags für fhem.service ist es etwas verändert zu finden...:
https://fhem.de/commandref_modular_DE.html#systemd_watchdog (https://fhem.de/commandref_modular_DE.html#systemd_watchdog)
Vielleicht kannst du mal versuchen, das entsprechend des ursprünglichen Vorschlags zu ergänzen und dann nochmal mit configDB (als service) starten? Falls es dann wieder oben sein sollte, mal schauen, ob das globale Attribut gesetzt ist und dort ggf. löschen.
ZitatUnd wo kommt dieses Verzeichnis überhaupt her, wenn es denn existiert?
ZitatEs existierte nicht, bis ich es wegen der Meldung heute Nachmittag mal manuell angelegt habe.
Konnte fhem dort lesen/schreiben?
Weiter gehts..
Das in /var/run/ erstellte Verzeichins /fhem wurde durch den Hardlink in /run verschoben und da wohl nicht gefunden. Wie auch immer.
Habe jetzt nochmal das /fhem-Verzeichnis mit fhem.dialout und Rechten 755 (drwxr-xr-x) unter /var/run erstellt.
Jetzt startet Fhem immernoch in Schleife aber mit neuer Fehlermeldung laut Log:
2022.10.11 13:17:22 0: configDB starting in rescue mode!
2022.10.11 13:17:22 3: telnetPort: port 7072 opened
2022.10.11 13:17:22 3: web: port 8083 opened
2022.10.11 13:17:22 0: Featurelevel: 6.1
2022.10.11 13:17:22 0: Server started with 4 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:fhem pid:23958)
2022.10.11 13:17:22 0: Server shutdown
2022.10.11 13:17:22 1: PERL WARNING: Use of uninitialized value $fileName in substitution (s///) at configDB.pm line 595.
2022.10.11 13:17:43 0: configDB starting in rescue mode!
2022.10.11 13:17:43 3: telnetPort: port 7072 opened
2022.10.11 13:17:44 3: web: port 8083 opened
2022.10.11 13:17:44 0: Featurelevel: 6.1
2022.10.11 13:17:44 0: Server started with 4 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:fhem pid:23965)
2022.10.11 13:17:44 0: Server shutdown
2022.10.11 13:17:44 1: PERL WARNING: Use of uninitialized value $fileName in substitution (s///) at configDB.pm line 595.
2022.10.11 13:18:05 0: configDB starting in rescue mode!
2022.10.11 13:18:05 3: telnetPort: port 7072 opened
2022.10.11 13:18:06 3: web: port 8083 opened
2022.10.11 13:18:06 0: Featurelevel: 6.1
2022.10.11 13:18:06 0: Server started with 4 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:fhem pid:23979)
2022.10.11 13:18:06 0: Server shutdown
2022.10.11 13:18:06 1: PERL WARNING: Use of uninitialized value $fileName in substitution (s///) at configDB.pm line 595.
In dem /var/run/fhem-Verzeichnis wird allerdings keine .pid-Datei angelegt.
Zeilen 594 bis 596 in configDB.pm ist
my $fileName = defined($data{saveID}) ? $data{saveID} : $configDB{loaded};
$fileName =~ s/^\s+|\s+$//g; # trim filenamqe
$fileName .= ".fhem.save";
Zitat von: Beta-User am 10 Oktober 2022, 21:49:30
Irgendwie klingt es danach, als würde das mit FHEM mit gestartet werden. Könnte auch was aus einer myUtils sein.
Vielleicht fördert das hier im Modul-Verzeichnis irgendwas zutage:
grep -i 'fhem.pid' *
Falls dieses neu angelegte Verzeichnis noch existiert, sollte es m.E. wieder gelöscht werden. Nicht, dass wir jetzt auch noch ein Rechte-Problem kurieren müssen...
Ausgabe von
grep -i 'fhem.pid' *10_EnOcean.pm: The FHEM PID controller calculates the actuator setpoint based on the temperature setpoint. The controller's
10_EnOcean.pm: The FHEM PID controller calculates the actuator setpoint based on the temperature setpoint. The controller's
10_EnOcean.pm: The FHEM PID controller calculates the actuator setpoint based on the temperature setpoint. The controller's
10_EnOcean.pm: Activate the Fhem PID regulator
98_systemd_watchdog.pm.vgb:ExecStop=+/usr/bin/pkill -F /run/fhem/fhem.pid
98_systemd_watchdog.pm.vgb:PIDFile=/run/fhem/fhem.pid
98_systemd_watchdog.pm.vgb: <code><kbd>attr global pidfilename /run/fhem/fhem.pid</kbd></code> konfiguriert werden kann.
98_systemd_watchdog.pm.vgb:ExecStop=+/usr/bin/pkill -F /run/fhem/fhem.pid
98_systemd_watchdog.pm.vgb:PIDFile=/run/fhem/fhem.pid
grep: FhemUtils: Ist ein Verzeichnis
grep: firmware: Ist ein Verzeichnis
grep: holiday: Ist ein Verzeichnis
grep: lib: Ist ein Verzeichnis
EnOcean nutze ich nicht.
Die systemd-watchdog.pm habe ich schon "deaktiviert". Die sucht aber sogar in /run/fhem nach der fhem.pid und nicht in /var/run/fhem wie in der Fehlermeldung zu Anfang.
Zitat von: VolkerGBenner am 11 Oktober 2022, 13:58:24
Die systemd-watchdog.pm habe ich schon "deaktiviert". Die sucht aber sogar in /run/fhem nach der fhem.pid und nicht in /var/run/fhem wie in der Fehlermeldung zu Anfang.
Das dürfte eh' nur die commandref sein, die diese Treffer erzeugt, siehe den Hinweis oben zur vermuteten "Quelle" für diese etwas seltsame Pfadangabe "/var/run/fhem". Daher der Vorschlag, die eventuell in global vorhandene "komische" Variante mit einem passenden Aufruf in der systemd-file zu versuchen. Aber betateilchen wird schon besser wissen, ob das globale Attribut ggf. gelesen wird oder nicht, ich habe nicht in den Code geschaut.
Was du vielleicht noch machen kannst: fhem.pl scheint ja relativ aktuell zu sein, trotzdem gibt es uU. auch zum Rest noch updates. Wenn du die demo-cfg startest, kannst du damit ein update anschubsen.
Ansonsten bin ich ratlos, was da direkt wieder einen (dieses Mal wohl geordneten) shutdown anweist.
Zitat von: VolkerGBenner am 11 Oktober 2022, 13:40:39
Jetzt startet Fhem immernoch in Schleife aber mit neuer Fehlermeldung laut Log:
...
Zeilen 594 bis 596 in configDB.pm ist
Das ist keine Fehlermeldung, sondern eine Warnung und sie hat nix mit Deinem pid Problem zu tun.
Die Meldung kommt daher, dass beim begonnenen shutdown versucht wird, ein statefile zu schreiben, was nicht funktioniert, weil Du immer noch im rescue mode bist.
Nimm mal das rescue aus der configDB.conf wieder raus und teste, wie sich Dein FHEM danach verhält.
Wie gehabt. Endlos Bootschleife mit
2022.10.11 15:10:14 2: eventTypes: loaded 1359 lines from ./log/eventTypes.txt
2022.10.11 15:10:16 1: HMCCU [myCCU3] CCU port 48181 is reachable
2022.10.11 15:10:16 1: HMCCU [myCCU3] Initialized version 5.0 222751518
2022.10.11 15:10:16 1: HMCCU [myCCU3] Initializing device
2022.10.11 15:10:16 2: HMCCU [myCCU3] Deleting old CCU configuration data
2022.10.11 15:10:16 2: HMCCU [myCCU3] Updating device table
2022.10.11 15:10:16 1: HMCCU [myCCU3] Read 38 devices with 321 channels from CCU 192.168.2.60
2022.10.11 15:10:16 1: HMCCU [myCCU3] Read 10 programs from CCU 192.168.2.60
2022.10.11 15:10:16 1: HMCCU [myCCU3] Read 8 virtual groups from CCU 192.168.2.60
2022.10.11 15:10:16 1: PERL WARNING: Argument "str*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 664.
2022.10.11 15:10:18 1: Watchdog Client: systemd watchdog is not available. Module inactive.
2022.10.11 15:10:19 2: HMCCURPCPROC [d_rpc002060VirtualDevices] CCU interface VirtualDevices doesn't support RPC multicalls
2022.10.11 15:10:19 1: HMCCURPCPROC [d_rpc002060VirtualDevices] Initialized version 5.0 222751518 for interface VirtualDevices with I/O device myCCU3
2022.10.11 15:10:20 2: HMCCURPCPROC [d_rpc002060BidCos_RF] CCU interface BidCos-RF supports RPC multicalls
2022.10.11 15:10:20 1: HMCCURPCPROC [d_rpc002060BidCos_RF] Initialized version 5.0 222751518 for interface BidCos-RF with I/O device myCCU3
2022.10.11 15:10:20 2: HMCCURPCPROC [d_rpc002060HmIP_RF] CCU interface HmIP-RF doesn't support RPC multicalls
2022.10.11 15:10:20 1: HMCCURPCPROC [d_rpc002060HmIP_RF] Initialized version 5.0 222751518 for interface HmIP-RF with I/O device myCCU3
2022.10.11 15:10:20 2: ONKYO_AVR PioneerVSX1131: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
/var/run/fhem/fhem.pid: No such file or directory
2022.10.11 15:10:42 2: eventTypes: loaded 1359 lines from ./log/eventTypes.txt
2022.10.11 15:10:43 1: HMCCU [myCCU3] CCU port 48181 is reachable
2022.10.11 15:10:43 1: HMCCU [myCCU3] Initialized version 5.0 222751518
2022.10.11 15:10:43 1: HMCCU [myCCU3] Initializing device
2022.10.11 15:10:44 2: HMCCU [myCCU3] Deleting old CCU configuration data
2022.10.11 15:10:44 2: HMCCU [myCCU3] Updating device table
2022.10.11 15:10:44 1: HMCCU [myCCU3] Read 38 devices with 321 channels from CCU 192.168.2.60
2022.10.11 15:10:44 1: HMCCU [myCCU3] Read 10 programs from CCU 192.168.2.60
2022.10.11 15:10:44 1: HMCCU [myCCU3] Read 8 virtual groups from CCU 192.168.2.60
2022.10.11 15:10:44 1: PERL WARNING: Argument "str*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 664.
2022.10.11 15:10:45 1: Watchdog Client: systemd watchdog is not available. Module inactive.
2022.10.11 15:10:47 2: HMCCURPCPROC [d_rpc002060VirtualDevices] CCU interface VirtualDevices doesn't support RPC multicalls
2022.10.11 15:10:47 1: HMCCURPCPROC [d_rpc002060VirtualDevices] Initialized version 5.0 222751518 for interface VirtualDevices with I/O device myCCU3
2022.10.11 15:10:47 2: HMCCURPCPROC [d_rpc002060BidCos_RF] CCU interface BidCos-RF supports RPC multicalls
2022.10.11 15:10:47 1: HMCCURPCPROC [d_rpc002060BidCos_RF] Initialized version 5.0 222751518 for interface BidCos-RF with I/O device myCCU3
2022.10.11 15:10:47 2: HMCCURPCPROC [d_rpc002060HmIP_RF] CCU interface HmIP-RF doesn't support RPC multicalls
2022.10.11 15:10:47 1: HMCCURPCPROC [d_rpc002060HmIP_RF] Initialized version 5.0 222751518 for interface HmIP-RF with I/O device myCCU3
2022.10.11 15:10:48 2: ONKYO_AVR PioneerVSX1131: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
/var/run/fhem/fhem.pid: No such file or directory
2022.10.11 15:11:10 2: eventTypes: loaded 1359 lines from ./log/eventTypes.txt
2022.10.11 15:11:11 1: HMCCU [myCCU3] CCU port 48181 is reachable
2022.10.11 15:11:11 1: HMCCU [myCCU3] Initialized version 5.0 222751518
2022.10.11 15:11:11 1: HMCCU [myCCU3] Initializing device
2022.10.11 15:11:12 2: HMCCU [myCCU3] Deleting old CCU configuration data
2022.10.11 15:11:12 2: HMCCU [myCCU3] Updating device table
2022.10.11 15:11:12 1: HMCCU [myCCU3] Read 38 devices with 321 channels from CCU 192.168.2.60
2022.10.11 15:11:12 1: HMCCU [myCCU3] Read 10 programs from CCU 192.168.2.60
2022.10.11 15:11:12 1: HMCCU [myCCU3] Read 8 virtual groups from CCU 192.168.2.60
2022.10.11 15:11:12 1: PERL WARNING: Argument "str*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 664.
2022.10.11 15:11:13 1: Watchdog Client: systemd watchdog is not available. Module inactive.
2022.10.11 15:11:15 2: HMCCURPCPROC [d_rpc002060VirtualDevices] CCU interface VirtualDevices doesn't support RPC multicalls
2022.10.11 15:11:15 1: HMCCURPCPROC [d_rpc002060VirtualDevices] Initialized version 5.0 222751518 for interface VirtualDevices with I/O device myCCU3
2022.10.11 15:11:15 2: HMCCURPCPROC [d_rpc002060BidCos_RF] CCU interface BidCos-RF supports RPC multicalls
2022.10.11 15:11:15 1: HMCCURPCPROC [d_rpc002060BidCos_RF] Initialized version 5.0 222751518 for interface BidCos-RF with I/O device myCCU3
2022.10.11 15:11:15 2: HMCCURPCPROC [d_rpc002060HmIP_RF] CCU interface HmIP-RF doesn't support RPC multicalls
2022.10.11 15:11:15 1: HMCCURPCPROC [d_rpc002060HmIP_RF] Initialized version 5.0 222751518 for interface HmIP-RF with I/O device myCCU3
2022.10.11 15:11:15 2: ONKYO_AVR PioneerVSX1131: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
/var/run/fhem/fhem.pid: No such file or directory
Ich hab nebenbei mal versucht eine neue Datenbank zu erstellen, wie im Commandref beschrieben. Da bekomme ich dann aber beim Aufruf mit
./fhem.pl configDB
die Fehlermeldung
PERL WARNING: DBD::SQLite::db do failed: table fhemversions has 3 columns but 2 values were supplied at configDB.pm line 344.
DBD::SQLite::db do failed: table fhemversions has 3 columns but 2 values were supplied at configDB.pm line 344.
Wenn ich alternativ starte mit ./fhem.pl fhem.cfg
stürzt Fhem nach configDB migrate mit der gleichen Fehlermeldung ab.
Hab auch schon nach dem Start mit der fhem.cfg ein "update" geamacht. Ändert nichts.
Benutzt du zufällig Monit zur Überwachung von Fhem?
https://forum.fhem.de/index.php?topic=30661.0 (https://forum.fhem.de/index.php?topic=30661.0)
Zitat von: frober am 11 Oktober 2022, 15:32:08
Benutzt du zufällig Monit zur Überwachung von Fhem?
https://forum.fhem.de/index.php?topic=30661.0 (https://forum.fhem.de/index.php?topic=30661.0)
Nein.
Zitat von: VolkerGBenner am 11 Oktober 2022, 13:58:24
Die systemd-watchdog.pm habe ich schon "deaktiviert".
Offenbar nicht wirklich, denn Du hast immer noch Meldungen, die aus diesem Modul kommen, in Deinem Startprozess.
Lösche die Datei 98_systemd_watchdog.pm vorläufig komplett aus Deinem FHEM Verzeichnis.
Zitat von: betateilchen am 11 Oktober 2022, 15:41:18
Offenbar nicht wirklich, denn Du hast immer noch Meldungen, die aus diesem Modul kommen, in Deinem Startprozess.
Lösche die Datei 98_systemd_watchdog.pm vorläufig komplett aus Deinem FHEM Verzeichnis.
:o Die hat das update gerade neu angelegt. Hab ich vergessen wieder raus zu nehmen.
Und wie ist nun der Zustand nach dem Löschen der Moduldatei?
Zitat von: betateilchen am 11 Oktober 2022, 14:21:58
Die Meldung kommt daher, dass beim begonnenen shutdown versucht wird, ein statefile zu schreiben, was nicht funktioniert, weil Du immer noch im rescue mode bist.
Zitat von: VolkerGBenner am 11 Oktober 2022, 15:22:24
die Fehlermeldung
DBD::SQLite::db do failed: table fhemversions has 3 columns but 2 values were supplied at configDB.pm line 344.
Die beiden Probleme sollten mit dem heutigen Update behoben sein.
Zitat von: betateilchen am 12 Oktober 2022, 09:25:16
Und wie ist nun der Zustand nach dem Löschen der Moduldatei?
Die beiden Probleme sollten mit dem heutigen Update behoben sein.
Ich kann jetzt Fhem als service mit einer nagelneu erstellten configDB.db starten und übers WEB erreichen.
2022.10.12 14:37:20 0: Featurelevel: 6.1
2022.10.12 14:37:20 0: Server started with 4 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:>
2022.10.12 14:37:33 0: Server shutdown
2022.10.12 14:53:37 3: telnetPort: port 7072 opened
2022.10.12 14:53:38 3: web: port 8083 opened
2022.10.12 14:53:38 1: Messages collected while initializing FHEM:SecurityCheck:
web is not password protected
telnetPort is not password protected
Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none
2022.10.12 14:53:38 0: Featurelevel: 6.1
2022.10.12 14:53:38 0: Server started with 5 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:>
2022.10.12 14:54:48 3: web_192.168.2.102_61534: unsupported HTTP method ^V^C^A^B^@^A^@^A�^C^Cq�V�8�$�{^Q�^_�ZH^Z�^P'>
Ersetze ich die configDB.db durch eine beliebige Version aus den letzten Backups bekomme ich wieder Endlosschleifen:
2022.10.12 14:50:48 2: eventTypes: loaded 1426 lines from ./log/eventTypes.txt
2022.10.12 14:50:49 1: HMCCU [myCCU3] CCU port 48181 is reachable
2022.10.12 14:50:49 1: HMCCU [myCCU3] Initialized version 5.0 222751518
2022.10.12 14:50:49 1: HMCCU [myCCU3] Initializing device
2022.10.12 14:50:50 2: HMCCU [myCCU3] Deleting old CCU configuration data
2022.10.12 14:50:50 2: HMCCU [myCCU3] Updating device table
2022.10.12 14:50:50 1: HMCCU [myCCU3] Read 38 devices with 321 channels from CCU 192.168.2.60
2022.10.12 14:50:50 1: HMCCU [myCCU3] Read 10 programs from CCU 192.168.2.60
2022.10.12 14:50:50 1: HMCCU [myCCU3] Read 8 virtual groups from CCU 192.168.2.60
2022.10.12 14:50:50 1: PERL WARNING: Argument "str*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 664.
2022.10.12 14:50:53 2: HMCCURPCPROC [d_rpc002060VirtualDevices] CCU interface VirtualDevices doesn't support RPC mul>
2022.10.12 14:50:53 1: HMCCURPCPROC [d_rpc002060VirtualDevices] Initialized version 5.0 222751518 for interface Virt>
2022.10.12 14:50:53 2: HMCCURPCPROC [d_rpc002060BidCos_RF] CCU interface BidCos-RF supports RPC multicalls
2022.10.12 14:50:53 1: HMCCURPCPROC [d_rpc002060BidCos_RF] Initialized version 5.0 222751518 for interface BidCos-RF>
2022.10.12 14:50:53 2: HMCCURPCPROC [d_rpc002060HmIP_RF] CCU interface HmIP-RF doesn't support RPC multicalls
2022.10.12 14:50:53 1: HMCCURPCPROC [d_rpc002060HmIP_RF] Initialized version 5.0 222751518 for interface HmIP-RF wit>
/var/run/fhem/fhem.pid: No such file or directory
Die systemd_Watchdog.pm und die ONKYO.pm hab ich gelöscht.
Gibt es eine Möglichkeit die Daten aus der Backup configDB.db in die frische Datenbank selectiv zu übertragen, um mögliche störende Einträge zu eliminieren? Andererseits kann es ja nicht sein, das die alten Datenbanken alle kaputt sind, weil es ja bis zum Zeitpunkt X noch gelaufen ist. :-(
Mir kommt es auch komisch vor, dass das Log mit
eventTypes: loaded 1426 lines from ./log/eventTypes.txt und nicht mit den üblichen Startmeldungen anfängt.
Es ist immer noch ein Rätsel, wieso irgendjemand nach dem nicht existierenden pid File sucht.
Wie sieht denn aktuell Deine fhem.service Datei aus?
Hast Du nach dem Bearbeiten der service-Datei das "systemctl daemon-reload" ausgeführt?
Zitat von: VolkerGBenner am 12 Oktober 2022, 15:06:56
Gibt es eine Möglichkeit die Daten aus der Backup configDB.db in die frische Datenbank selectiv zu übertragen, um mögliche störende Einträge zu eliminieren? Andererseits kann es ja nicht sein, das die alten Datenbanken alle kaputt sind, weil es ja bis zum Zeitpunkt X noch gelaufen ist. :-(
Die Datenbanken sind nicht kaputt, Du hast aber devices in Deiner Konfiguration gespeichert, die in Deinem FHEM Probleme verursachen.
Zitat von: VolkerGBenner am 12 Oktober 2022, 15:06:56
Mir kommt es auch komisch vor, dass das Log miteventTypes: loaded 1426 lines from ./log/eventTypes.txt und nicht mit den üblichen Startmeldungen anfängt.
Die 1426 Zeilen eventTypes werden übrigens auch aus der configDB gelesen - insofern ist die Datenbank selbst nicht kaputt.
*grübel* was ist eigentlich DAS?
Zitat von: VolkerGBenner am 12 Oktober 2022, 15:06:56
2022.10.12 14:54:48 3: web_192.168.2.102_61534: unsupported HTTP method ^V^C^A^B^@^A^@^A�^C^Cq�V�8�$�{^Q�^_�ZH^Z�^P'>
Zitat von: VolkerGBenner am 12 Oktober 2022, 15:06:56
Die systemd_Watchdog.pm und die ONKYO.pm hab ich gelöscht.
Was hat denn ONKYO jetzt hier zu suchen?
Im Vergleich zu vorher:
2022.10.10 16:43:36 1: PERL WARNING: Argument "str*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 664.
2022.10.10 16:43:37 1: Watchdog Client: systemd watchdog is not available. Module inactive.
2022.10.10 16:43:40 2: HMCCURPCPROC [d_rpc002060VirtualDevices] CCU interface VirtualDevices doesn't support RPC multicalls
wird jetzt:
2022.10.12 14:50:50 1: PERL WARNING: Argument "str*" isn't numeric in numeric gt (>) at ./FHEM/88_HMCCU.pm line 664.
2022.10.12 14:50:53 2: HMCCURPCPROC [d_rpc002060VirtualDevices] CCU interface VirtualDevices doesn't support RPC mul>
zumindest innerhalb von FHEM nicht mehr nach systemd watchdog gesucht. Das Löschen der zugehörigen Moduldatei scheint also an der Stelle zu wirken.
Aber die Meldung
/var/run/fhem/fhem.pid: No such file or directorysieht mir gar nicht danach aus, dass sie aus FHEM kommt.
Vermutlich stammt die irgendwoher aus dem Betriebssystem.
Zitat von: betateilchen am 12 Oktober 2022, 16:06:39
*grübel* was ist eigentlich DAS?
War nur einmalig. Ist bei weiteren reboots nicht mehr aufgetaucht.
Zitat von: betateilchen am 12 Oktober 2022, 16:23:32
Was hat denn ONKYO jetzt hier zu suchen?
Wegen dem:
2022.10.11 15:10:20 2: ONKYO_AVR PioneerVSX1131: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
/var/run/fhem/fhem.pid: No such file or directoryist die letzte Meldung vorm Austieg. Wollte nur die Möglichkeit ausschliessen, dass es an dem Modul liegt. Das benutze ich fürs Heimkino.
Die Reihenfolge im Log hat vermutlich nichts mit dem Onkyo zu tun.
Im Moment habe ich eher HMCCU in Verdacht.
Hab mir gerade Deine configDB angeschaut.
attr|myCCU3|ccuGetVars|str*|Das ist m.E. eine falsche Syntax für das gesetzte Attribut, das erklärt auf jeden Fall die Perl Warnung in Deinem Log.
Vermutlich hast Du vergessen, ein Interval anzugeben, in der commandref steht:
Zitat
ccuGetVars <interval>:[<pattern>]
Read CCU system variables periodically and update readings. If pattern is specified only variables matching this expression are stored as readings.
Da ist zwar das pattern optional, das Intervall aber nicht.
Ob das zum Absturz von FHEM führt, kann ich aber nicht einschätzen, mit HMCCU arbeite ich selbst nicht.
Aber das hier in Deiner Konfiguration könnte zum Absturz führen:
attr|global|pidfilename|/var/run/fhem/fhem.pid|
Zitat von: betateilchen am 12 Oktober 2022, 16:59:31
Hab mir gerade Deine configDB angeschaut.
attr|myCCU3|ccuGetVars|str*|
Das ist m.E. eine falsche Syntax für das gesetzte Attribut, das erklärt auf jeden Fall die Perl Warnung in Deinem Log.
Vermutlich hast Du vergessen, ein Interval anzugeben, in der commandref steht:
Da ist zwar das pattern optional, das Intervall aber nicht.
Ob das zum Absturz von FHEM führt, kann ich aber nicht einschätzen, mit HMCCU arbeite ich selbst nicht.
Aber das hier in Deiner Konfiguration könnte zum Absturz führen:
attr|global|pidfilename|/var/run/fhem/fhem.pid|
Wenn du das lesen kannst, könntest du das korrigieren? :-)
Zitat von: VolkerGBenner am 12 Oktober 2022, 17:02:55
Wenn du das lesen kannst, könntest du das korrigieren? :-)
Was meinst Du, wozu Du mir Deine Datenbank schicken solltest? 8)
Zitat von: betateilchen am 12 Oktober 2022, 17:05:19
Was meinst Du, wozu Du mir Deine Datenbank schicken solltest? 8)
Hast du den Rumms gespürt ? Das war der Stein der mir vom Herzen gefallen ist ;D
Ich habe wieder Zugang.
Das Log zeigt keine Fehler mehr an.
Die Kommunikation zur piccu3 funktioniert soweit.
1000 Dank für die Hilfe.
Zitat von: VolkerGBenner am 12 Oktober 2022, 17:28:32
Die Kommunikation zur piccu3 funktioniert soweit.
Das Intervall in der HMCCU habe ich bei ccuGetVars auf 300 Sekunden gesetzt - Du musst bitte noch prüfen, ob das für Deine Anwendung passt.
Mach bitte noch ein [gelöst] vor den Titel im ersten Beitrag dieses Threads, danke.
Zitat von: betateilchen am 12 Oktober 2022, 17:33:15
Das Intervall in der HMCCU habe ich bei ccuGetVars auf 300 Sekunden gesetzt - Du musst bitte noch prüfen, ob das für Deine Anwendung passt.
Das ccuGetVars hatte ich nur mal testweise genutzt und dann nicht weiter beachtet. Danke für den Hinweis.
Thema ist abgeschlossen.