FHEMWEB: Sporadisch fehlende SVG-Plots mit plotfork

[Flachzange]

Hallo zusammen,

bei mir wurden in Räumen mit vielen SVG-Plots immer wieder einzelne Diagramme nicht angezeigt. Nach einem Neuladen war dann häufig ein anderes Diagramm betroffen. Oft waren mehrere Diagramme betroffen.

Das Problem trat sowohl beim direkten Zugriff auf FHEMWEB als auch über einen Reverse-Proxy auf. Dort war passend dazu folgender Fehler zu sehen:

Code Auswählen Erweitern

recv() failed (104: Connection reset by peer) while reading response header from upstream

Der entscheidende Test war:

Code Auswählen Erweitern

attr WEB plotfork 0
Damit trat das Problem nicht mehr auf. Mit plotfork 1 war es wieder reproduzierbar.

Offenbar beendet sich der Fork-Kindprozess nach der SVG-Ausgabe, ohne dem HTTP/1.1-Client vorher mitzuteilen, dass die Verbindung geschlossen wird. Browser beziehungsweise Proxy können die Verbindung deshalb für den nächsten SVG-Request wiederverwenden und laufen dann sporadisch in einen Connection Reset.

Ich habe testweise in 01_FHEMWEB.pm im Child-Zweig folgende Zeile ergänzt:

Code Auswählen Erweitern

} elsif(defined($pid)){                   # child
  delete $hash->{BUF};
  $hash->{isChild} = 1;
  $FW_headerlines .= "Connection: close\r\n";
}
Seitdem laufen die SVGs auch mit plotfork 1 zuverlässig und weiterhin performant. Mehrfaches Neuladen mit vielen parallelen Diagrammen erzeugt weder fehlende Plots noch weitere Connection Resets.

Getestet habe ich mit:

01_FHEMWEB.pm 31325 2026-06-01
plotEmbed 2
plotfork 1

Vielleicht könnte jemand prüfen, ob "Connection: close" bei Antworten aus dem Fork-Kindprozess grundsätzlich ergänzt werden sollte?

Danke und Gruß

Chris

[rudolfkoenig]

Ich gehe davon aus, dass es an der Kombination Browser/Client liegt, da plotEmbed=2/plotfork=1 seit langem die Voreinstellung ist fuer alle Multiprozessor-Rechner.

Was hast Du fuer ein OS beim Client und beim Server, und was fuer einen Browser verwendet Du?

Kannst Du bitte pruefen, ob das FHEMWEB Attribut closeConn eine Abhilfe ist?

[Flachzange]

Hallo Rudolf,

ich habe es vorhin getestet. Das Problem tritt damit ebenfalls auf und um ehrlich zu sein überrascht mich das nicht, denn closeConn bildet ja nur das ab, was plotfork 1 im jeweiligen Child-Thread eh macht: den Socket schließen.

Das zugrundeliegende Probleme scheint zu sein, dass die jeweiligen Clients die Verbindungen aus Effizienzgründen wiederverwenden möchten, weil sie davon ausgehen, dass sie noch existieren (was aber nicht der Fall ist).

Das Problem habe ich schon sehr sehr lange, eher Jahre als Monate.

Getestete Clients:
- Firefox z.B. Version 155 unter Windows 10/11
- Edge z.B. Version 152 unter Windows 10/11
- Nginx Proxy Manager 2.15.1 (docker)

Die Tatsache, dass es auch mit NPM als Reverse Proxy auftritt schließt für mich ein spezifisches Client-Problem praktisch aus.

FHEM läuft ebenfalls unter Docker im Image: Derzeit: ghcr.io/fhem/fhem-docker:5-threaded-bookworm

Aber wie gesagt: Ich mache die Beobachtunge schon sehr lange, war nur lange auch zu träge, um mich damit zu beschäftigen.

Sieht dann so bei mir aus:
Du darfst diesen Dateianhang nicht ansehen.