[Muzaffer Keklik]

Hallo zusammen,

bei unserer nativen OTOBO-Installation erscheinen im Minutentakt folgende Warnungen im MariaDB-Log:

 2026-10-13 12:13:10 22 [Warning] Aborted connection 22 to db: 'otobo' user: 'otobo' host: 'localhost' (Got an error reading communication packets)
2026-10-13 12:13:11 23 [Warning] Aborted connection 23 to db: 'otobo' user: 'otobo' host: 'localhost' (Got an error reading communication packets)
2026-10-13 12:13:12 10 [Warning] Aborted connection 10 to db: 'otobo' user: 'otobo' host: 'localhost' (Got an error reading communication packets)
2026-10-13 12:14:54 64 [Warning] Aborted connection 64 to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (This connection closed normally without authentication)
2026-10-13 12:17:54 86 [Warning] Aborted connection 86 to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (This connection closed normally without authentication)

Aufgrund vorheriger Datenbankprobleme mussten wir MariaDB vollständig deinstallieren (purge) und anschließend neu installieren. Die ursprünglichen Datenbankprobleme sind damit behoben; OTOBO ist weiterhin im Betrieb und funktioniert aktuell.

Die Ursache der oben genannten Warnungen konnten wir bislang jedoch nicht eingrenzen.

Über Hinweise, welche Protokolle und Konfigurationseinstellungen wir zur Ursachensuche prüfen sollten, würden wir uns sehr freuen.

Vielen Dank für eure Unterstützung.

[marcel-graf]

Hi Muzaffer,

wir nutzen aktuell nur noch die Docker Umgebung. Kann mich aber erinnern, dass wir in der mysqld conf den Wert max_allowed_packet = 128M angepasst haben.

Gruß Marcel

[Muzaffer Keklik]

Hallo Marcel,

den Wert für max_allowed_packet haben wir bereits auf ein 1G erhöht.

Folgende Dateien haben wir angepasst:

• /etc/mysql/conf.d/mysqldump.cnf
• /etc/mysql/mariadb.conf.d/50-server.cnf

Gruß
Muzaffer

[Muzaffer Keklik]

Ich habe den Log-Level von der Datenbank erhöht: SET GLOBAL log_warnings = 4;

Dennoch kann ich keine Hinweise finden wo die Ursache ist:

2026-10-13 15:01:24 901 [Warning] Could not read packet: fd: 62 state: 1 read_length: 4 errno: 11 vio_errno: 1158 length: 0
2026-10-13 15:01:24 901 [Warning] Aborted connection 901 to db: 'otobo' user: 'otobo' host: 'localhost' (Got an error reading communication packets)
2026-10-13 15:02:54 1161 [Warning] Could not read packet: fd: 222 state: 1 read_length: 3 errno: 0 vio_errno: 1158 length: 0
2026-10-13 15:02:54 1161 [Warning] Aborted connection 1161 to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (This connection closed normally without authentication)

 

[Arnold]

Hallo,

das klingt wie etwas, dass am besten hier besprochen werden sollte: https://github.com/RotherOSS/otobo

Viele Grüße
Arnold

• Diese Antwort wurde vor 3 Wochen, 2 Tagen von Arnold geändert.

[Muzaffer Keklik]

Hallo Arnold,

bevor ich das Problem auf GitHub veröffentliche, habe ich gestern noch etwas weiter recherchiert und dabei folgende Fehlermeldung gefunden:

/opt/otobo/var/log/Daemon/SchedulerCronTaskManagerERR-1791883837.log:1:DBI connect('database=otobo;host=127.0.0.1','otobo',...) failed: Can't connect to server on '127.0.0.1' (115) at /usr/share/perl5/DBIx/Connector.pm line 31.

Diese Fehlermeldung tritt wiederholt in mehreren Log-Dateien auf. Betroffen sind folgende Dateien:

• /opt/otobo/var/log/Daemon/SchedulerCronTaskManagerERR-1791883837.log
• /opt/otobo/var/log/Daemon/SchedulerFutureTaskManagerERR-1791886077.log
• /opt/otobo/var/log/Daemon/SchedulerFutureTaskManagerERR-1791883826.log
• /var/log/apache2/error.log

Die Meldung deutet darauf hin, dass OTOBO zeitweise keine Verbindung zur MariaDB-Datenbank über 127.0.0.1 herstellen kann.

Habt ihr Ideen, woran das liegen könnte, oder Hinweise, welche Logs, Konfigurationen oder Dienste ich als Nächstes überprüfen sollte?

Vielen Dank für eure Unterstützung!

Viele Grüße
Muzaffer

[Arnold]

Hallo Muzaffer,

warum Teile von OTOBO nicht mit der Datenbank sprechen können, kann ich dir ohne Analyse nicht sagen. Native Installationen haben leider sehr viele Freiheitsgrade. Ich würde ganz am Anfang anfangen: Läuft der Datenbankprozess in der Zeit in der OTOBO sich nicht verbinden kann? Wie ist der Datenbankprozess gesteuert? Wo liegen die Logs des Prozessmanagement?  (ich könnte mir vorstellen, dass der OOM-Killer die Datenbank beendet und Systemd diese dann wieder neu startet).

Ich würde mittelfristig den Umstieg auf Docker empfehlen (für den Hinterkopf).

Viel Erfolg
Arnold

[Muzaffer Keklik]

Ursachenanalyse / Problemlösung: Got an error reading communication packets

Die Konfigurationsdatei /etc/apache2/mods-available/mpm_prefork.conf anpassen.

Dabei wurde der Parameter MaxSpareServers von 10 auf 20 erhöht.

 

Ursachenanalyse: This connection closed normally without authentication

Die Ursache dieser Warnmeldung wurde dem SNMP-basierten Zertifikatscheck vom Monitoring-Tool zugeordnet.

Der relevante Konfigurationseintrag lautet:

extend certificate_mariadb_connection /usr/lib/nagios/plugins/check_ssl_cert --host localhost --match otobo.myDomain.de --port 3306 --protocol mysql --check-chain --ignore-ocsp --warning 30 --critical 15

Der Eintrag verwendet das Plugin check_ssl_cert, um das MariaDB-Zertifikat über eine Verbindung zu localhost auf Port 3306 zu überprüfen. Für diese Zertifikatsprüfung wird keine reguläre Datenbankauthentifizierung durchgeführt. Das Beenden dieser Verbindung erzeugt den entsprechenden Warnhinweis im MariaDB-Log.

Die Ursache der Warnmeldung wurde identifiziert.

[Autor]

Beiträge