forum.opsi.org

m.radtke hat geschrieben: ↑25 Jun 2021, 15:14 ein Uograde auf opsi 4.2 hat bei vielen Leuten geholfen dieses Problem zu lösen.

Na dann werde ich mal,...

Das Problem scheint sich tatsächlich erledigt zu haben.

Dafür habe ich jetzt ein anderes, aber nicht in diesem Thread

Hallo,

uns ist das Problem jetzt auch mehrfach untergekommen (opsiconfd version 4.1.1.20). Ein Update auf die 4.2 ist aktuell aber nicht machbar (ist aber schon eingeplant).
Was mir in dem Zusammenhang noch aufgefallen ist, sind die vielen offenen TCP verbindungen des opsiconfd. Für jeden Client, der dort anfragt werden drei Verbindungen aufgemacht, die aber offensichtlich nicht wieder geschlossen werden. Sie behalten den Status Established. Nach einer Weile sind das dann bei uns über 500. Die Verbindungen tauchen aber nicht auf der Info Seite unter active oder expired sessions auf. Nach Neustart des opsiconfd werden die Verbindungen dann nach und nach wieder weggeräumt (FIN_WAIT1/FIN_WAIT2).

Keine Ahnung ob die Anzahl der Verbindungen irgendwann zum Problem wird oder mit dem Problem nichts zu tun hat, zumal ich auch nicht weiß, ob das ggf. schon immer so war. Aber vielleicht hat ja noch jemand ne Idee, was man außer dem Upgrade auf die 4.2 noch machen könnte.

Gruß
Thomas

Hallo,

das Problem besteht bei uns noch.
opsiconfd version 4.1.1.20
python-opsi version 4.1.1.101
auf Debian9

Bei unserem Server kann der opsiconfd.service 601 TCP-Verbindungen aufbauen, dann werden keine weiteren mehr aufgebaut und der Service hängt.
Mit systemctl oder journalctl sind keine Fehler zu sehen, auch das opsi-log, dass wir zeitweise auf Loglevel 8 hatten hat keine Fehler aufgezeichnet.

In der opsiconfd.conf haben wir die Werte
max inactive interval
und
max sessions per ip
verringert, das verzögert den Aufbau der Verbindungen etwas, aber dennoch erreichen wir das Limit von 601 Verbindungen täglich.

Der aktuelle Workaround wird wohl ein cronjob sein der die Menge der Verbindungen abfragt und ggfs. den service neu startet. (das ist eine furchtbare Lösung, aber bisher die einzige, die wir gefunden haben)

Das Problem besteht aber nur bei unserem Hauptserver(configserver), unsere Depotserver haben dieses Problem nicht.

# --- Nachtrag --- #

Der Parameter 'maxSessionsPerIp' in opsiconfd.conf wird anscheinend ignoriert. Das lässt sich mit dem diesem Befehl überprüfen: Damit werden die Verbindungen von Opsi aufgelistet, an ':' zerschnitten und der Teil mit der Client IP ausgewählt, sortiert und zusammengezählt.
Ich kam auf über 50 Verbindungen für einzelne IPs.