Endlosschleife Logdateien an Server senden

[n.klinger]

Hallo,

wir setzen seid kurzem opsi für unsere Schulungsrechner ein. Es kommt aber immer wieder auf einige Geräten vor, dass die beim Senden der Logdateien in eine Art Endlosschleife geraten (wir haben schon mehrere Stunden gewartet). Das einzige was bleibt ist, dass man die Rechner herunterfährt.
Auf dem Server seh ich währenddessen keinerlei Auslastung.
Soweit ich das beurteilen kann passiert das vorallem wenn man mehrere Softwareprodukte installiert.

Hat jemand eine Idee woran das liegen könnte bzw. ob man eine Art Timeout einstellen kann?

Schonmal vielen Dank im voraus.

Gruß
Nico

[n.wenselowski]

Hallo Nico,

die einfachen Möglichkeiten sind hier das Aktualisieren auf die neuen Versionen von opsi / opsi-client-agent / opsi-winst.

Passiert das Hängen immer nur bei bestimmten Produkten?
Reagiert der Webservice in der Zeit auf andere Anfragen?

Gruß

Niko

[n.klinger]

Hallo Niko,

Danke für deine Antwort.

Ich habe gerade ein safe-upgrade auf dem Server durchgeführt. opsi wurde jdoch nicht aktualisiert, war wohl auf dem aktuellen Stand. Für den Fall, dass ich einen Fehler gemacht habe hier die Versionen:
- opsi-client-agent (4.0.5.4-2)
- opsi-winst (4.11.4.17-1) ist jedoch auf keinem der Notebooks installiert
- opsi (4.0.5.2.11)

Der Webservice ist normal erreichbar und er hat auch schon die Info, dass die Produkte installiert wurden. Lediglich die Logdateien fehlen. Auf dem Server ist auch keinerlei Auslastung zu erkennen.
Es passiert nicht bei bestimmten Produkten. Ich habe (um den Fehler zu testen) für unsere Notebooks eingestellt, dass die etwa 15-20 Programme installieren sollen.
Ich habe bisher nur drei Notebooks davon angeschlossen und die Installationen durchlaufen lassen.
Beim ersten ist der Fehler aufgetreten und bei den anderen beiden nicht.

Die Notebooks sind identisch bis auf eine Sache, die ich überprüfen möchte. Und zwar ist auf einigen Geräten sw-audit nicht installiert. Aber ich kann mir eigentlich nicht vorstellen, dass es damit zusammenhängt.

Gruß
Nico

[n.wenselowski]

Hallo Nico,

Die Notebooks sind identisch bis auf eine Sache, die ich überprüfen möchte. Und zwar ist auf einigen Geräten sw-audit nicht installiert. Aber ich kann mir eigentlich nicht vorstellen, dass es damit zusammenhängt.

Sag niemals nie

Nur um sicher zu gehen würde ich mal folgendes machen:

Code: Alles auswählen

opsi-set-rights
service opsiconfd restart

Siehst du im opsiconfd-Log des Clients, dass er einen Aufruf zum Schreiben der Logs macht (Methode log_write oder write_log)?


Gruß

Niko

[n.klinger]

Hallo Niko,

ich habe sw-audit mal überprüft, indem ich auf 10 Notebooks 23 Produkte hab installieren lassen. Vier Geräte konnten keine Logs senden. Bei dieser Installation war sw-audit nicht dabei.

Als ich erstmals sw-audit auf den Notebooks installieren wollte gab es auf einigen Geräte Probleme. Da war es auch so, dass die das Ergebnis nicht an den Server senden konnten. Allerdings wurde der Server zu knapp 100% ausgelastet und z.T. auch nur durch ein Notebook. Ich habe den Auftrag zur Installation rausgenommen. Dadurch ist sw-audit laut Weboberfläche auf einigen Geräten installiert auf einigen ist der Status unknown (installiert), auf anderen ist kein Hinweis, dass es mal einen Status gab und bei wieder anderen ist es auf failed.

Allerdings war es gemischt alle vier Stati kammen sowohl bei denen vor, die Logs senden konnten als auch bei denen die keine Logs senden konnten.

Ich habe auf dem Server im Verzeichnis (/var/log/opsi/opsiconfd) Logs von allen Notebooks Logs gefunden und mir ist aufgefallen, dass am Ende immer sw-audit abgefragt wird und zwar bei allen.

Code: Alles auswählen

[5] [Jun 29 09:41:02] -----> Executing: getProduct_hash(u'swaudit', u'SERVER') (JsonRpc.py|125)
[4] [Jun 29 09:41:02] Failed to read opsi modules file '/etc/opsi/modules': [Errno 2] No such file or directory: u'/etc/opsi/modules' (Backend.py|386)
[5] [Jun 29 09:41:02] -----> Executing: productOnClient_getObjects(u'', {'productType': u'LocalbootProduct', 'clientId': u'NOTEBOOK', 'productId': u'swaudit'}) (JsonRpc.py|125)
[4] [Jun 29 10:03:03] Failed to read opsi modules file '/etc/opsi/modules': [Errno 2] No such file or directory: u'/etc/opsi/modules' (Backend.py|386)

Wird sw-audit immer am Ende abgefragt, wenn es mal den Befehl zur Installation gab?

Ich habe die Befehle nicht ausgeführt, da der Fehler aus meiner Sicht nicht mit Zugriffsrechten zu tun hat und ich zudem nicht wusste auf welchen Ordner ich das hätte anwenden sollen. Den Dienst habe ich ebenfalls nicht neu gestartet, da wir kürzlich den Server auf eine andere Maschine umgezogen haben und dementsprechend neu gestartet wurde. Trotzdem Danke

Ich werde die Tage sw-audit auf den betroffenen Geräten erneut installieren und eine Liste erstellen. Vielleicht bringt das neue Erkenntnisse.

Ich habe die Logs auf den Clients geprüft. Mir ist was aufgefallen, als ich zwei miteinander verglichen habe.
Im opsiconfd-Log steht am Ende bei fast jedem Befehl

Code: Alles auswählen

{installation_pending}

allerdings werden auf die selben Befehle aufgerufen wie auf einem Notebook, dass Logs senden kann.

Im Install-Log ist mir aufgefallen, dass es einfach bei der Nachricht

Code: Alles auswählen

Shrinking Log to 5MB

aufhört. Dieser Befehl wird auf Notebooks, die Nachricht taucht auf Notebooks die Logs senden können garnicht auf.
Mir ist auch aufgefallen, dass in einem älteren Log anscheinend noch Logs gesendet werden konnten. Dies sehe ich auch auf dem Server.

Gruß
Nico

[d.oertel]

Hi,

bitte mal den Inhalt c:\opsi.org\log in eine zip-Datei packen und mir zu senden: d.oertel(at)uib.de

Ich schaue es mir dann an.

gruß
d.oertel

[n.klinger]

Hallo,

ich habe mal auf einer Gruppe von Rechnern swaudit durchlaufen lassen. Dabei ist mir aufgefallen, dass die Methoden auditSoftware_createObjects und auditSoftwareOnClient_createObjects sehr viel Last auf dem Server verursachen. Anscheinend werden dort Hashes berechnet allerdings frage ich mich warum und ob man das beschleunigen kann.

Ich habe auch Software installieren lassen und die Logs wurden gesendet was schonmal sehr gut ist. Bei einigen hat das Senden eine Stunde gedauert. Und zwar war das der Befehl

Code: Alles auswählen

Shrinking Log to 5 MB

Die wurden von 30 MB auf 5 MB verkleinert. Ich frage mich, ob man die größe der Logs vorgeben kann, um den Prozess zu beschleunigen.

Gruß
Nico

[n.wenselowski]

Dabei ist mir aufgefallen, dass die Methoden auditSoftware_createObjects und auditSoftwareOnClient_createObjects sehr viel Last auf dem Server verursachen. Anscheinend werden dort Hashes berechnet allerdings frage ich mich warum und ob man das beschleunigen kann.

Es werden keine Hashes berechnet, sondern es wird hash als Synonym für dictionaries verwendet. Das ist eine relativ simple Aktion, an der sich wenig ändern lässt.
Beschleunigen kann man die Inventur in der Regel durch die Verwendung von MySQL für die Inventarisierung - dafür ist das Backend auch frei.

Die Konfigurierbarkeit der Loggröße ab der verkleinert wird ist mir momentan nicht bekannt.

Gruß

Niko

[n.klinger]

Hallo Niko,

vielen Dank für die Antwort. Ich habe das Backend neu konfiguriert und es hat einen deutlichen Unterschied bei sw-audit gemacht. sw-audit läuft jetzt problemlos und schnell. Es verursacht auch deutlich weniger Last auf dem Server.

Es gibt nur eine Sache, die ich nicht verstehe. Und zwar haben einige Notebooks noch das Problem mit dem Senden der Logdateien. Das scheint auch sporadisch aufzutreten. Die hängen dabei alle an dem "Shrinking Log to 5 MB". Obwohl ich auf identischen Notebooks die selbe Software installieren lasse (letzter Test 20 Softwareprodukte), senden einige Notebooks direkt die Logfiles ohne große Verzögerung während die anderen dafür eine Stunde brauchen.

Währenddessen verursacht der opsi-scipt Prozess immer 30-36% Prozessorlast obwohl der Prozess als inaktiv gekennzeichnet ist. Auf den Datenträger und dem Netzwerkadapter wird keine Last verursacht.

Als nächstes werde ich testen, ob das Problem auch auftritt wenn ich nur ein Softwareprodukt installieren lasse, denn dann sollte das Logfile von vornherein nicht größer als 5 MB sein.

Mir ist auch aufgefallen, dass die Notebooks, die die Logdateien problemlos senden "Shrinking Log to 5 MB" garnicht ausführen, obwohl das Log z.B. 60 MB groß ist.
Ich frage mich warum einige Notebooks das ausführen und andere nicht.

Gruß
Nico

[n.klinger]

Hallo,

Ich habe mal die Größen der Logs verglichen. Auf den Notebooks, die die Logs direkt senden sind die Logs 60 MB groß während die Logs auf den anderen Notebooks zwischen 36 und 39 MB groß sind.

Auf dem Server jedoch sind alle Logs 5 MB groß oder kleiner. Woraus ich schließe, dass in beiden Fällen die Logs gekürzt werden. Jedoch rufen nur die Notebooks, mit den 36-39 MB großen Logs die Methode zum verkleinern der Logs auf (laut Log) und dies dauert dann eine Stunde.

Gibt es eine Möglichkeit, dies zu beschleunigen?

Gruß
Nico