[erledigt] krieg fhem unter buster nicht zum starten

[the ratman]

nö, spionagetools hab ich ned an fhem dran *g*

fragt sich jetzt nur: was kann man nu wirklich machen, ohne dass das den nebengeschmack eines workarounds hat?
meine: otto hat da ja viel geschrieben, aber ich weiss ned mal, ob das nur seine tests und erkenntnisse draus sind, oder da schon irgendwo ne lösung dabei steht.
wissts ja: arbeiten andere baustelle, cheffe!

[frank]

https://manpages.debian.org/buster/manpages-de/systemd.service.5.de.html

hier wird bei Type=forking zusätzlich "PIDFile=" empfohlen.

daher habe ich jetzt mal "attr global pidfilename fhem.pid" gesetzt und in fhem.service "PIDFile=/opt/fhem/fhem.pid" eingrtragen.

jetzt sieht das stoppen von fhem über shutdown im syslog unter stretch bei mir "sauberer" aus.

vielleicht hat das bei euch unter buster auch positive einflüsse.

[Otto123]

Das waren bisher mehr Tests, Ergebnisse und Ideen - die Lösung arbeitet noch an sich
@Frank das schau ich mir an ...

[Wernieman]

@Ratman:
Wenn Du die Config in der DB hast, solltest Du eventuell fhem erst nach mysql starten ...

[the ratman]

ich hab derzeit noch gar keine db am neuen fhem angeschlossen - wollt nur berichten, was ich mir denk.
derzeit wart ich drauf, dass mir otto nen auftrag gibt, was für ihn am neuen system zu testen, oder jemand die lösung hat, die dann auch "irgendwie offiziell" wird.

[the ratman]

gibts schon neues otto?

[Otto123]

leider nein. Obwohl ich Informationen und Ideen sammle, habe ich noch nichts konkret getestet.
Und ich fühle mich etwas unwohl dabei einen "offiziellen" Vorschlag zu machen. Eigentlich weiß ich dafür zu wenig über systemd.
Aber ich habe es nicht vergessen

[the ratman]

kein leider ...
bin schon froh, dass du überhaupt was für machst.
und vielleicht is ja wer hier, der das lustige systemd besser kennt?

ich selber würd halt nicht gern "irgendwas" tun, wenn dann vielleicht eine "offizielle" lösung für fhem raus kommt.
hast dann irgendwann mal doppelt gemoppelt und was drittes spinnt wieder genau deswegen <-- jaja, ich kenn das verhalten von linux langsam ;O\

[the ratman]

hab mich mal wieder gepsielt und einfach meine db im buster fhem aktiviert.

ist jetzt natürlich nur ne bestätigung der obigen aussagen, aber nur zur vollständigkeit: mit db und deren 10 sek. wartezeit gibts kein doppeltes neustarten von fhem.

[Otto123]

blöd nachgefragt: wo ist die Wartezeit? Du meinst configDb? wie sieht da jetzt Deine  fhem.service aus?

[the ratman]

also was ich meine is das modul "DbLog"
mit der "db.conf" als file, in der meine mysql daten drinnen stehen.

sobald ich das angelegt hatte, meint fhem beim restarten:

Code Auswählen Erweitern

2020.05.08 16:24:31 1:  Server shutdown delayed due to logdb for max 10 sec
2020.05.08 16:24:32 0:  Server shutdown
2020.05.08 16:24:33 1:  Including fhem.cfg
~snip~und schon gibts auch auf dem frisch aufgesetzten fhem unter buster kein doppelstarten mehr. und dabei nimmt der eh nur 1 sek. von den 10 möglichen.

nehm ichs modul wieder raus, startet fhem auch wieder doppelt. es muß also nur ne verzögerung kommen, damit das verhalten wieder "normal" is. stand aber schon weiter oben, auch mit erklärung, welche module noch verzögern würden.

meine ... is sicher keine lösung, aber immerhin ne info *g*


nachtrag:
fhem.service hab ich nix gedreht - is 100% natürlicher anbau.

[Otto123]

Hi,

Nachdem ich jetzt gefühlt alle Dokumente über systemd auf freedesktop.org gelesen und die meisten Parameter auch probiert habe, nachdem ich versucht habe sie zu verstehen - sende ich SIGHUP 🥴 Hangup

Das Resumé für das hier erwähnte Problem Doppel(Re)start von FHEM:

• entweder man hat das Problem nicht, weil man wie im Beispiel DbLog sowieso eine shutdown Verzögerung hat
  
• oder man verwendet, wie schon mal gesagt, den Zusatz RestartSec=2 im Unit-File - mMn bevorzugt und minimal.
  

Resumé Ende

Ich kann nicht aufhören zu labern, deswegen geht es weiter:
Wenn man aus FHEM heraus ein shutdown machen will (FHEM ausschalten), dann kann man anstatt Restart=always | Restart=on-success verwenden und anstatt nur shutdown | shutdown 1 verwenden. Damit wird dem system signalisiert: FHEM wurde fehlerhaft beendet und wird damit nicht neu gestartet.
shutdown oder shutdown restart führt wie vorher zum Neustart von FHEM.
Diese Einstellung läuft aber konträr zu der Idee: Wenn FHEM fehlerhaft beendet wurde soll es einfach neu starten - wer will das? (Man kann das mit systemd sicher clever machen - das ist aber mehr als ein Parameter: Nich gucken - IMMER Neustart

Infos am Rande:
Hier wurde der Einbau des Parameters  "1" beim shutdown Befehl und eine andere Variante für die Parameter im unit file diskutiert. Diese haben aus meiner Sicht den Nachteil, dass systemd gar nicht mitbekommt, dass fhem beendet wurde. FHEM ist nach shutdown einfach weg und in systemd sagt der Status aktiv. Man muss erst (nochmal) stop machen bevor man wieder start machen kann.

Startet man FHEM nicht mit systemd, sondern einfach interaktiv mit dem Befehl:

Code Auswählen Erweitern

cd /opt/fhem
sudo perl fhem.pl fhem.cfg
funktioniert der Befehl shutdown und auch der Befehl shutdown restart wie in der Doku beschrieben.
Unter systemd ist der restart Parameter mMn wirkungslos, ich habe es in keiner Kombination hinbekommen. Der (Neu)start vom fhem Prozess wird von systemd quasi abgewürgt und je nach Konfiguration in der fhem.service unit von systemd übernommen (u.U. 2 mal)

Ich muss mal noch überlegen, wo ich den Rest meiner Testergebnisse hinschreibe

Gruss Otto

[the ratman]

ich darf also kurz mal n noob-resüme ziehen?

nix wirklich bösartiges, nicht gefärlich, auch nicht für zukünftiges und maximal nervig für den 0815-user?

is das soweit korrekt?

[Otto123]

Ja  ihopeso

[the ratman]

dann dank ich dir für deine mühen und trau mich jetzt endlich mal mein fhem aktiv machen *g*!