Alte Frage - altes Problem - unregelmaessige Neustarts

[Otto123]

Also ich bin ja Linux Anfänger, deswegen antworte ich meistens vorsichtig und nach dem ich etwas gelesen habe:

Proxmox 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 FHEM
Da 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

[Wernieman]

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 ...

[Wolfgang Hochweller]

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 :

Code Auswählen Erweitern


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 :

Code Auswählen Erweitern


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.

[Otto123]

Erscheinen da Ausgaben auf der Console?
Was gibt Dir

Code Auswählen Erweitern

list global logfileoder

Code Auswählen Erweitern

cat fhem.cfg|grep "attr global logfile"

[amenomade]

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 :

Code Auswählen Erweitern


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.

Code Auswählen Erweitern

#!/usr/bin/perl
use strict;
use warnings;
fork;
sleep 30;

Starte ich mit /usr/bin/perl fork.pl:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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
Entweder 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.

[Otto123]

global 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!

[amenomade]

fhem.pl:

Code Auswählen Erweitern

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 }

[Otto123]

überredet danke

[Wolfgang Hochweller]

Danke für die Beispiele, so weit, verstanden.

Code Auswählen Erweitern


list global logfile


gibt mir

Code Auswählen Erweitern


global                   ./log/fhem-%Y-%d.log


Datei ist vorhanden und wird auch gefüllt.


im fhem.cfg steht   

Code Auswählen Erweitern


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 !

[amenomade]

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?  

[Wolfgang Hochweller]

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.

[Otto123]

Wenn man weiß wonach man sucht stehts sogar ordentlich in der Doku:

nofork
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.