die Paketinstallation auf einigen unserer Clients wird nicht ausgeführt. Teilweise scheint es an der Initialisierung bzw. Aufrechterhaltung der Verbindung zwischen Server und Client zu liegen, da die Pakete entweder offen bleiben (angefordert, nicht ausgeführt), oder zum Teil zb eine Batch-Datei als failed angezeigt wird, welche sonst fehlerfrei läuft. Teilweise hängt sich auch das swaudit Paket auf, zufällig habe ich dies einmal mitbekommen, es hang bei "writing results back to server" und wurde dann schließlich als failed deklariert.
Um der Sache auf den Grund zu gehen habe ich die Logs nach Keywords wie timeout, error, failed etc. durchsucht. Leider fehlt mir bei sämtlichen Clients ein Ansatz, da sich in den Logs keine Timeout-Detail Fehler finden lassen. Der Install-Log ist zum Beispiel auch leer, da die Pakete ja nicht ausgeführt werden.
Was wäre ein geeigneter Ansatz dem Problem auf die Spur zu kommen?
Ich habe bei einem Client, bei dem sämtliche Pakete offen bleiben, beispielsweise folgendes im opsiconfd Log:
Code: Alles auswählen
(1445) [5] [Nov 21 04:16:22] Session 'S8i81UhYQNWc0l7N4QkW09uPZu156i2V' from ip 'x.x.x.x', application 'opsiclientd version 4.0.83' expired after 120 seconds (Session.py|184)
(1446) [5] [Nov 21 04:16:22] Session currently in use, waiting before deletion (Session.py|186)
(1447) [4] [Nov 21 04:24:07] Failed to read opsi modules file '/etc/opsi/modules': [Errno 2] No such file or directory: u'/etc/opsi/modules' (Backend.py|386)
(1448) [5] [Nov 21 04:24:07] Application 'opsiclientd version 4.0.83' on client 'x.x.x.x' did not send cookie (workers.py|168)
(1449) [5] [Nov 21 04:24:07] New session created (session.py|75)
(1450) [5] [Nov 21 04:24:08] Authorization request from host hostname@x.x.x.x (application: opsiclientd version 4.0.83) (workers.py|193)
(1451) [4] [Nov 21 04:24:08] Failed to read opsi modules file '/etc/opsi/modules': [Errno 2] No such file or directory: u'/etc/opsi/modules' (Backend.py|386)
(1452) [5] [Nov 21 04:29:58] -----> Executing: backend_getInterface() (JsonRpc.py|125)
(1453) [5] [Nov 21 04:30:08] Session 'S8i81UhYQNWc0l7N4QkW09uPZu156i2V' from ip 'x.x.x.x', application 'opsiclientd version 4.0.83' deleted (Session.py|211)In der Opsiconfd-Info zeigt das Diagramm längere Zeit 100%tige CPU Auslastung an. Ist der Server trotz XEON CPU mit der gleichzeitigen Abhandlung von ca. 15-20 Clients (Clients werden per Windows-Aufgabenplanung gleichzeitg durch Starten des Opsi-Dienstes "aufgeweckt) überfordert oder ist die 100% Auslastung üblich? (Auslastung heißt ja nicht automatisch gleich Überforderung?)
Anschlussfrage wäre dann: Das gesamte Backend läuft aktuell noch auf File-Basis: Ab wie vielen Clients bei gleichzeitiger Abhandlung ist das File-Backend überfordert und ein Upgrade auf mySQL Pflicht? Entlastet es den CPU-Load maßgeblich wenn das Backend für die SWInventur auf mySQL umgestellt wird oder ist der Anteil der Inventarisierung am Gesamt CPU-Load zu vernachlässigen?
Danke!
