Erste morgendlicher Configed-Editor-Connect endet in "Keine Verbindung - Internal Server Error"

[mensch90]

Guten Morgen,
ich betreibe insgesamt drei OPSI-Server.
Zwei von diesen haben morgens das merkwürdige Problem, dass der erste Admin-Login in einem "Keine Verbindung - Internal Server Error" endet.
Ein sofortiger Neuversuch resultiert immer in einem Erfolg.
Leider, da ich nicht alle Clients überblicke, ist mir nicht klar, ob dies nur die Admin-Configed-Loginmethode betrifft oder aber auch den Client Connect.
Weder im MYSQL-Error-Log, noch im Syslog, noch in den anderen Server-OPSI-Logs finde ich Hinweise auf das Problem. Es scheint, als würde ein Dienst/DB schlafen und erst dann geweckt werden.
Einziger Unterschied zwischen den zwei OPSI-Servern mit Problemen und dem einen ohne: IPTABLES STATEFULL-Firewall dazwischen mit den typischen "NEW, ESTABLISHED,RELATED" Regeln. Dieses Setup lief mit einem älteren OPSI für Windows 7 Clients ohne Probleme.

Umgebung:
- Latest OPSI-Stable Server, Configed und Clients
- Debian Stretch

Vielen Dank für Tipps

[koepkek]

Hallo

im Configed im Hilfe Menü findest du den aktuellen Logfile. Vielleicht steht dort was hilfreiches drin.
An der selben Stelle kann auch der Loglevel erhöht werden.

Hoffe das bringt dich weiter

Schönen Tag

Karsten Köpke

[r.roeder]

nur noch ein Tipp: wenn der configed meldet "Internal Server Error", dann erhält er vom Server nicht die erbetenen Infos, sondern halt nur die Nachricht, dass etwas schief läuft im Server. Das können z.B. defekte Daten im Backend sein oder sonst so eklige Dinge.
Also beim Server in dessen Logs schauen (/var/log/opsi/opsiconfd und eventuell in der opsiconfd.conf das Log level hochdrehen)

Viel Erfolg

[mensch90]

Vielen Dank für die TIpps.
Ich konnte, so glaube ich, folgende Regelmäßigkeit erkennen:

Code: Alles auswählen

[3] [Jan 23 04:07:09]   File "/usr/lib/python2.7/dist-packages/OPSI/Service/Worker.py", line 289, in _errback
    failure.raiseException()
 (Logger.py|798)
[3] [Jan 23 04:07:09]   File "<string>", line 2, in raiseException
 (Logger.py|798)
[3] [Jan 23 04:07:09]      ==>>> (2006, 'MySQL server has gone away') (Worker.py|298)
[3] [Jan 23 04:07:09] [Failure instance: Traceback: <class '_mysql_exceptions.OperationalError'>: (2006, 'MySQL server has gone away')
/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:651:_runCallbacks
/usr/lib/python2.7/dist-packages/opsiconfd/workers.py:421:_getCallInstance
/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:150:maybeDeferred
/usr/lib/python2.7/dist-packages/opsiconfd/workers.py:341:_getBackend
--- <exception caught here> ---
/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:150:maybeDeferred
/usr/lib/python2.7/dist-packages/opsiconfd/workers.py:338:_createBackend
/usr/lib/python2.7/dist-packages/OPSI/Backend/BackendManager.py:1049:backendManagerFactory
/usr/lib/python2.7/dist-packages/OPSI/Backend/BackendManager.py:238:__init__
/usr/lib/python2.7/dist-packages/OPSI/Backend/Depotserver.py:64:__init__
/usr/lib/python2.7/dist-packages/OPSI/Backend/Backend.py:1933:host_getIdents
<string>:1:host_getObjects
/usr/lib/python2.7/dist-packages/OPSI/Backend/Backend.py:524:_executeMethod
<string>:1:host_getObjects
/usr/lib/python2.7/dist-packages/OPSI/Backend/BackendManager.py:437:_dispatchMethod
/usr/lib/python2.7/dist-packages/OPSI/Backend/SQL.py:1088:host_getObjects
/usr/lib/python2.7/dist-packages/OPSI/Backend/MySQL.py:315:getSet
/usr/lib/python2.7/dist-packages/OPSI/Backend/MySQL.py:514:execute
/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py:226:execute
/usr/lib/python2.7/dist-packages/MySQLdb/connections.py:36:defaulterrorhandler
] (Worker.py|299)
[5] [Jan 23 04:07:29] Application 'opsi config editor 4.1.9.3.3' on client '192.168.1.116' did not send cookie (workers.py|185)
[2] [Jan 23 04:07:29] Traceback: (Logger.py|798)
[2] [Jan 23 04:07:30]   File "/usr/lib/python2.7/dist-packages/OPSI/Service/Worker.py", line 289, in _errback
    failure.raiseException()
 (Logger.py|798)
[2] [Jan 23 04:07:30]   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 651, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
 (Logger.py|798)
[2] [Jan 23 04:07:30]   File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 193, in _getSession
    WorkerOpsi._getSession(self, result)
 (Logger.py|798)
[2] [Jan 23 04:07:30]   File "/usr/lib/python2.7/dist-packages/OPSI/Service/Worker.py", line 389, in _getSession
    sessionId = self._getSessionId()
 (Logger.py|798)
[2] [Jan 23 04:07:30]   File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 432, in _getSessionId
    return WorkerOpsiconfd._getSessionId(self)
 (Logger.py|798)
[2] [Jan 23 04:07:30]   File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 188, in _getSessionId
    raise OpsiAuthenticationError(u"Application '%s' on client '%s' did neither supply session id nor password" % (self._getUserAgent(), self.request.remoteAddr.host))

MySql im Standardconfigverhalten schließt DB-Connections nach 8 Stunden idle-Verhalten.
Ich bin mir jedoch nicht sicher, ob der erste Client morgens dieses Problem nicht zeigt, sondern nur die Configed-Editor-Requests - es müsste jedoch doch analog ein Gone-Away-Fehler geben, da die DB-Connection ja vom auf dem Server laufenden OPSI-Dienst Richtung MySQL getriggert wird.

Die Frage lautet ja eher: warum ist der Connection-Request nicht erfolgreich - ist nur ein Reconnect.

Den Mysql-Idle-Timeout auf sehr hohe Werte zu setzen, könnte Nebenwirkungen haben - mit welchen Werten arbeitet ihr?

Vielen Dank!

[mensch90]

Gerade gefunden und werden den Fix mal testen - danke für das tolle Handbuch - man muss es nur lesen....


Manualle Konfiguration
Manuelle Konfiguration kann über die Backend-Konfigurations-Datei erfolgen. Diese ist standardmäßig /etc/opsi/backends/mysql.conf.

Seit python-opsi 4.1.1.76 ist es möglich die Erstellung neuer Verbindungen nach einer bestimmten Zeit zu forcieren, um Probleme mit Timeouts zu vermeiden. Ein Indikator für solche Timeouts kann die Meldung mysql server has gone away sein.

Sie können einen Timeout setzen, indem Sie für connectionPoolRecycling angeben nach wievielen Sekunden eine neue Verbindung erstellt werden soll. Der Standardwert ist -1, welcher keine erzwungene Neu-Erstellung von Verbindungen bedeutet. Wird diesert Wert gesetzt, sollte er in der Regel niedriger als der auf dem Server konfigurierte Wert für Verbindungs-Timeouts (wait_timeout) sein.