Meine Installation startet alle paar Minuten neu und ich finde nicht heraus, warum.
Stacktrace sieht so aus, als würde der Server ganz normal runterfahren und neustarten.
gassistant, tradfri, database, alle werden vor dem Neustart ordentlich runtergefahren
Wie kann ich sowas eingrenzen ?
Hast Du einen Watchdog auf dem System?
Ist es ein systemd-System? Wie sieht die Config aus?
Hi,
wenn systemd - was sagt denn
journalctl -u fhem.service
Gruß Otto
Das sagt so etwas :
Sep 16 16:35:20 howifhem systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Sep 16 16:35:20 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Sep 16 16:35:20 howifhem systemd[1]: Stopped FHEM Home Automation.
Sep 16 16:35:20 howifhem systemd[1]: Starting FHEM Home Automation...
Sep 16 16:36:50 howifhem systemd[1]: fhem.service: Start operation timed out. Terminating.
Sep 16 16:36:51 howifhem systemd[1]: fhem.service: Failed with result 'timeout'.
Sep 16 16:36:51 howifhem systemd[1]: Failed to start FHEM Home Automation.
Sep 16 16:36:51 howifhem systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Sep 16 16:36:51 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 2.
Sep 16 16:36:51 howifhem systemd[1]: Stopped FHEM Home Automation.
Sep 16 16:36:51 howifhem systemd[1]: Starting FHEM Home Automation...
Sep 16 16:38:21 howifhem systemd[1]: fhem.service: Start operation timed out. Terminating.
Sep 16 16:38:22 howifhem systemd[1]: fhem.service: Failed with result 'timeout'.
Sep 16 16:38:22 howifhem systemd[1]: Failed to start FHEM Home Automation.
Sep 16 16:38:23 howifhem systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Sep 16 16:38:23 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 3.
Sep 16 16:38:23 howifhem systemd[1]: Stopped FHEM Home Automation.
Sep 16 16:38:23 howifhem systemd[1]: Starting FHEM Home Automation...
Sep 16 16:39:53 howifhem systemd[1]: fhem.service: Start operation timed out. Terminating.
Sep 16 16:39:54 howifhem systemd[1]: fhem.service: Failed with result 'timeout'.
Sep 16 16:39:54 howifhem systemd[1]: Failed to start FHEM Home Automation.
Sep 16 16:39:54 howifhem systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Sep 16 16:39:54 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 4.
Sep 16 16:39:54 howifhem systemd[1]: Stopped FHEM Home Automation.
Sep 16 16:39:54 howifhem systemd[1]: Starting FHEM Home Automation...
Sep 16 16:41:24 howifhem systemd[1]: fhem.service: Start operation timed out. Terminating.
Sep 16 16:41:25 howifhem systemd[1]: fhem.service: Failed with result 'timeout'.
Bei 'Start operation timed out' klingelt da was bei mir, muss nur noch drauf kommen, was das war
Irgendwas mit Mehrfachstart ? Fork ?
Versuch mal das hier, schadet auf alle Fälle nicht:
https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Restart_verz.C3.B6gern
Mit sudo systemctl edit --full fhem.service
Gruß Otto
Also der restart ist definitiv von systemd ausgelöst:
Sep 16 16:35:20 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
...
Sep 16 16:36:51 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 2.
...
Sep 16 16:38:23 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 3.
...
Sep 16 16:39:54 howifhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 4.
...
Sep 16 16:41:24 howifhem systemd[1]: fhem.service: Start operation timed out. Terminating.
Sep 16 16:41:25 howifhem systemd[1]: fhem.service: Failed with result 'timeout'.
Ja wegen dem Timeout und dem Standard RestartSec=100ms - der startet ja quasi in kurzer Schleife
Jep .. habe mein Post mal ergänzt ....
Auf jedem falle sollte man "Restart verzögern" aus dem von Dir verlinkten Bereich verwenden:
Stickwort RestartSec
Alternativ einfach den Restart komplett abschalten
Stichwort Restart
Danke.
Restart verzoegern hat nichts gebracht.
Das Problem hängt vielleicht auch mit dem System zusammen.
Auf dem Pi kam das nicht vor, soweit ich mich erinnern kann.
Jetzt läuft FHEM in einem Linux-Container und ich meine, ich hätte das gleiche Problem gehabt,
als mein FHEM mal auf einen Stand-alone Debian lief.
Was damals half, und jetzt auch wieder, ist 'forking' durch 'simple' zu ersetzen.
Was das jetzt für negative Konsequenzen haben kann, übersehe ich nicht.
Wo jetzt? Im systemd watchdog? :o
Ein Docker-Container?
Oder was verstehst Du unter "Linux-Container" ... das wird doch normalerweise nicht durch systemd gestartet ...
Wir hatten mal im docker-Thread auch so ein Problem .. aber da ich selber FHEM nicht unter docker verwende, kann ich Dir da nicht helfen. Müsstest Du mal selber suchen ...
Das 'simple' ersetzt das 'forking' in fhem.service.
Der Container ist ein lxc-container unter Proxmox.
Das ist keine Lösung - das ist ne Krücke. Damit läuft FHEM meines Erachtens nicht wie geplant.
Wie ist FHEM in den Container gekommen?
Wobei ich keine Ahnung von Proxmox habe.
FHEM kommt in den Container wie sonst auch bei einer Installation und wird dort auch gepflegt, ist ja kein Docker-Container.
Was koennte denn bei 'simple' schiefgehen ?
No restart hoert sich auch nicht gesund an, da muss ich ja wohl selbst aufpassen, ob FHEM noch laeuft ?
Ich richte mich dabei nach diesen Erfahrungen :
a) If the service starts and keeps running, and the prompt does not return until you press Control-C or stop the service in some other way: then Type = simple is the right choice.
b) If the prompt returns but the service keeps running in the background (i.e. the service daemonizes itself on its own), then Type = forking is the right choice.
FHEM faellt unter a), es sei denn, das Startkommando ist nicht korrekt. ( /usr/bin/perl fhem.pl fhem.cfg )
Dann gucke doch mal, wie Proxmox Container (Ja es sind Container wie Docker, nur ohne Serverprozess und unter Proxmox laufen auch Docker-Container) normalerweise gestartet werden. Du solltest also nicht bei FHEM, sondern bei Proxmox schauen ...
Also ich bin ja Linux Anfänger, deswegen antworte ich meistens vorsichtig und nach dem ich etwas gelesen habe:
ZitatProxmox VE stellt zwei Virtualisierungstechnologien auf einer Plattform bereit. Dies bietet Ihnen maximale Flexibilität für Ihre virtualisierte IT-Infrastruktur. Verwenden Sie KVM für virtuelle Maschinen und Container für leichtgewichtige Linux-Anwendungen.
Für mich war bisher Proxmox mehr VM als Container - offenbar gibt es beides. Was also zu klären wäre, was hat Wolfgang genau?
Systemd und der Start von FHEMDa habe ich auch viel gelesen und mich mit Tests beschäftigt, sagen kann ich dazu folgendes:
- ursprünglich ist FHEM so gebaut, dass wenn der Prozess mit root Rechten gestartet wird, ein Child Prozess mit user fhem gestartet wird und er Startprozess wird beendet. Das Verhalten kann man durch einen manuellen Start mit sudo /usr/bin/perl fhem.pl fhem.cfg im Pfad /opt/fhem sehr gut beobachten.
- das alte init.d Script hat das genau so gemacht, je nach Installationszeitraum von FHEM wurde dann man einfach dieses Script "im Kompatibilitätsmodus" von systemd mit Type=forking gestartet
- das neue Systemd Script von Udo macht das anders, dort wird der Prozess sofort mit user fhem aber auch mit Type=forking gestartet
- Wird /usr/bin/perl fhem.pl fhem.cfg.demo mit irgendeinem user gestartet, kehrt der Ursprungsprozess von FHEM nicht zurück sondern bleibt aktiv, das Verhalten ist also in der cfg konfigurierbar
- Wird /usr/bin/perl fhem.pl fhem.cfg mit irgendeinem user gestartet und vorher mit sudo chmod 666 ./log/fhem-2020-09.log die Rechte gesetzt, kehrt der Startprozess von FHEM zurück und FHEM läuft nicht mit user fhem sondern im aufrufenden Userkontext
- Aus meiner Sicht ist Type=forking für den Start von FHEM richtig
Ich vermute im Fall von Wolfgang ist systemd der Meinung der Prozess läuft nicht mehr (systemd kann den Prozess offenbar nicht überwachen) und muss neu gestartet werden. Das ist für mich ein Fehler, den ich beseitigen würde.
Gruß Otto
Mein Fehler .. habe mich gerade durch podman ablenken lassen ... Otto Du hast mit proxmox recht. Warscheinlich hat er eine VM innerhalb von Proxmox und den systemd dann innerhalb der VM ....
Aber das ist nur geraten ...
Jein.
Ueber Docker und Proxmox sind wir uns einig - macht nicht viel Sinn.
Ich verwende kein VM, sondern LXC-Container, das ist fast so wie ein vollständiges System.
Was den Child-Prozess angeht :
So wie es jetzt ist , kommt sudo /usr/bin/perl fhem.pl fhem.cfg nicht von alleine zurück, sondern muss manuell beendet werden.
So sieht das aus :
root 1463 0.0 0.0 7224 3604 pts/2 S+ 10:54 0:00 sudo /usr/bin/perl fhem.pl fhem.cfg
fhem 1464 0.0 3.5 156568 143896 pts/2 S+ 10:54 0:07 /usr/bin/perl fhem.pl fhem.cfg
Der Root-Prozess lebt weiter !
Wenn ich aber als user root /usr/bin/perl fhem.pl fhem.cfg ausfuehre, sieht das so aus :
fhem 1553 0.0 3.4 153640 140996 pts/2 S+ 10:57 0:02 /usr/bin/perl fhem.pl fhem.cfg
Sieht ja eigentlich schon besser aus, das Terminal bleibt aber blockiert, der fhem-Prozess laeuft nicht im Hintergrund.
Bei Forking erwartet doch das System, dass das EXEC-Kommando aus fhem.service sich selbst beendet, nachdem es einen anderen Prozess gestartet hat.
Passiert aber nicht, also läuft das ganze in einen Timeout und startet dann neu.
Ich könnte probieren, den Service ohne Timeout laufen zu lassen.
Selbst wenn es funktioniert, etwas stimmt hier nicht.
Erscheinen da Ausgaben auf der Console?
Was gibt Dir list global logfileoder
cat fhem.cfg|grep "attr global logfile"
Zitat von: Wolfgang Hochweller am 17 September 2020, 11:09:28
Was den Child-Prozess angeht :
So wie es jetzt ist , kommt sudo /usr/bin/perl fhem.pl fhem.cfg nicht von alleine zurück, sondern muss manuell beendet werden.
So sieht das aus :
root 1463 0.0 0.0 7224 3604 pts/2 S+ 10:54 0:00 sudo /usr/bin/perl fhem.pl fhem.cfg
fhem 1464 0.0 3.5 156568 143896 pts/2 S+ 10:54 0:07 /usr/bin/perl fhem.pl fhem.cfg
Der Root-Prozess lebt weiter !
Jein. sudo macht selbst ein fork. Das sieht man gut mit folgendem Programm fork.pl.
#!/usr/bin/perl
use strict;
use warnings;
fork;
sleep 30;
Starte ich mit /usr/bin/perl fork.pl:
pi 20864 0.4 0.4 10528 4124 pts/1 S+ 11:51 0:00 /usr/bin/perl fork.pl
pi 20865 0.0 0.0 10528 528 pts/1 S+ 11:51 0:00 /usr/bin/perl fork.pl
Starte ich mit sudo /usr/bin/perl fork.pl:
root 21086 0.2 0.3 10024 3204 pts/1 S+ 11:54 0:00 sudo /usr/bin/perl fork.pl
root 21091 0.0 0.4 10528 4040 pts/1 S+ 11:54 0:00 /usr/bin/perl fork.pl
root 21092 0.0 0.0 10528 528 pts/1 S+ 11:54 0:00 /usr/bin/perl fork.pl
In deinem Beispiel:
root 1463 0.0 0.0 7224 3604 pts/2 S+ 10:54 0:00 sudo /usr/bin/perl fhem.pl fhem.cfg
fhem 1464 0.0 3.5 156568 143896 pts/2 S+ 10:54 0:07 /usr/bin/perl fhem.pl fhem.cfgEntweder hat sich fhem nicht geforkt (hast Du das global Attribut nofork vielleicht gesetzt? Oder die Logfile ist nicht erreichbar? Oder sudo handelt SIG und oder Filedescriptors anders) Laut ProzessID (nur +1) kann es sein)
Oder fhem hat sich doch geforkt (am Ende läuft er eh unter User fhem), und der Hauptprozess lebt nicht mehr.
In dem Fall hast Du:
- einen Prozess sudo
- dieses sudo forkt /perl fhem
- /perl fhem forkt sich selbst
Das ist der sudo Prozess, der nicht zurück kommt.
Aber ich gebe zu: unter root bleibt das Terminal blockiert
Was vielleicht helfen könnte, wäre pidfilename zu setzen, und auch im service zu definieren.
Zitatglobal Attribut nofork
das hat doch nix mit dem fhem.pl Prozess an sich zu tun!? Ich dachte das ist doch nur für svg usw. ?Ich tippe auch auf das LogFile!
fhem.pl:
588 # Go to background if the logfile is a real file (not stdout)
589 if($^O =~ m/Win/ && !$attr{global}{nofork}) {
590 $attr{global}{nofork}=1;
591 }
592 if($attr{global}{logfile} ne "-" && !$attr{global}{nofork}) {
593 defined(my $pid = fork) || die "Can't fork: $!";
594 exit(0) if $pid;
595 }
überredet :) danke
Danke für die Beispiele, so weit, verstanden.
list global logfile
gibt mir
global ./log/fhem-%Y-%d.log
Datei ist vorhanden und wird auch gefüllt.
im fhem.cfg steht
attr global nofork 1
Wenn ich das nofork auskommentiere, kann ich forking im Service benutzen, geht ohne Probleme.
Der Eintrag im .cfg steht schon lange da drin, auf Anhieb weiß ich nicht mehr, wieso.
Mal sehen, ob es einen Grund dafür gab.
Danke an alle !
Wie Du im Code oben sehen kannst, setzt fhem auf Windows Systemen standardmässig nofork 1.
Falls Du mal mit Windows angefangen hast und dann auf Linux "portiert" hast, kann es eine Ursache gewesen sein.
"auskommentieren" heisst, Du editierst fhem.cfg manuell? ??? :-X
Nein, eher selten , wofür haben wir denn den Editor ?
Das mit dem Windows-Hinweis kann sehr gut sein; meine Installation hat schon viele Phasen erlebt, auch Windows.
Wenn man weiß wonach man sucht stehts sogar ordentlich in der Doku:
Zitatnofork
If set and the logfile is not "-", do not try to background. Needed on some Fritzbox installations, and it will be set automatically for Windows.
:-[