-
AutorBeiträge
-
-
19. Oktober 2023 um 17:05 Uhr - Views: 347 #15745
Hallo,
wir haben mit unserem OTOBO folgendes Problem:
- Ausgehende E-Mails werden nicht verschickt sondern befinden sich in einer Warteschleife
Vorgeschichte:
- Das Kennwort des zum Mailversand genutzten Mailaccounts wurde geändert (beim Mailingdienst).
- Am Folgetag wurde das Kennwort in der OTOBO Webmaske (SENDMAIL SMTPTLS) eingepflegt
- Vor der Passwortänderung im Kommunikationsprotokoll zuerwartende auth Fehlermeldung. Nach der Passwortänderung scheinen die Mails in einer Schleife zu hängen. Der Schritt eines Eintrags im Komm. Protokol:
Successfully queued message for delivery (To: ‘root@localhost’, From: ‘support@unseredomain.de’, Subject: ‘OTOBO Scheduler Daemon Cron: MailQueueSend’). - OTOBO Version 10.1.4
- Docker-installation nach Anleitung
Versuchte Problemlösung:
- Neustart des Webservers
- Manuelles verschicken der Mails auf dem Webserver. Allerdings liefern alle Commands auf der MailQueue folgende Fehlermeldung:
./bin/otobo.Console.pl Maint::Email::MailQueue --list --verbose
Error message for ./bin/otobo.Console.pl Maint::Database::Check (checks connectivity to database):
Message: Can't connect to MySQL server on 'db' (115)- Beim Wechsel auf den db Docker Container und manuellen einwählen in die dortige Datenbank findet sich weder eine otobo Datenbank noch Nutzer.
Fragen:
- Da das Ticketsystem an sich funktionsfähig ist, und auch durch eingehende Mails weiter Tickets erstellt werden usw. muss die SQL Datenbank ja irgendwo sein. Wo könnte ich einen Hinweis darauf finden wo die aufgestöbert werden kann?
- Wie ließe sich die Verbindung zwischen otobo.Console und MailQueue wieder herstellen? Damit die ausstehende Mail Schlange als mögliche Problemlösung einmal gelöscht werden kann.
Vielen Dank für alle Hinweise!
-
20. Oktober 2023 um 9:36 Uhr #15747
Hallo Thorsten,
im Log steht nichts weiter dazu?
Wurde mal ein kompletter Serverneustart gemacht bzw. ein Cache delete + Rebuild
sudo docker exec -it otobo_web_1 bash
cd bin
./otobo.Console.pl Maint::Cache::Delete
./otobo.Console.pl Maint::Config::Rebuild –cleanup
Wenn du in den Container mit “sudo docker exec -it otobo_db_1 bash” wechselst, und dich mit “mysql -u root -p” + Kennwort in die Datenbank einloggst, siehst du dann überhaupt Datenbanken?
SHOW Database;
+——————–+
| Database |
+——————–+
| information_schema |
| mysql |
| otobo |
| performance_schema |
+——————–+SHOW Tables;
Hier gibt es noch ein SMTPS Problem im Forum, eventuell hilft das auch: https://otobo.io/de/forums/topic/smtps-modul-hat-ploetzlich-aufgehoert-zu-funktionieren/
Gruß Marcel
-
20. Oktober 2023 um 11:50 Uhr #15749
Hallo Marcel,
danke für deine Tipps.
In den Logs konnte ich bislang nichts weiter finden was auf das Mail Problem hinweist.
Der Aufruf von Cache::Delete , Config::Rebuild liefert wieder Fehler mit Hinweis auf die Datenbank.
otobo@48d8fb355133:~/bin$ ./otobo.Console.pl Maint::Cache::Delete
Deleting cache…
ERROR: OTOBO-otobo.Console.pl-Maint::Cache::Delete-10 Perl: 5.34.1 OS: linux Time: Fri Oct 20 09:31:27 2023Message: Redis error: !
Traceback (134530):
Module: Kernel::System::Cache::Redis::_Connect Line: 253
Module: Kernel::System::Cache::Redis::CleanUp Line: 177
Module: Kernel::System::Cache::CleanUp Line: 417
Module: Kernel::System::Console::Command::Maint::Cache::Delete::Run Line: 79
Module: (eval) Line: 480
Module: Kernel::System::Console::BaseCommand::Execute Line: 474
Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
Module: ./otobo.Console.pl Line: 35otobo@48d8fb355133:~/bin$ ./otobo.Console.pl Maint::Config::Rebuild -cleanup
DBI connect(‘database=otobo;host=db;’,’otobo’,…) failed: Can’t connect to MySQL server on ‘db’ (115) at /opt/otobo_install/local/lib/perl5/DBIx/Connector.pm line 31.
ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.34.1 OS: linux Time: Fri Oct 20 09:34:15 2023Message: Can’t connect to MySQL server on ‘db’ (115)
Traceback (134579):
Module: Kernel::System::DB::Prepare Line: 767
Module: Kernel::System::PID::PIDGet Line: 169
Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 79
Module: (eval) Line: 465
Module: Kernel::System::Console::BaseCommand::Execute Line: 465
Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
Module: ./otobo.Console.pl Line: 35SHOW DATABASES auf otobo_db_1 bash
zeigt die otobo Datenbank nicht mit an sondern liefert nur:
+——————–+
| Database |
+——————–+
| information_schema |
| mysql |
| performance_schema |
+——————–+Auch in der User Tabelle von mysql taucht auch der otobo user nicht mit auf.
-
-
20. Oktober 2023 um 11:05 Uhr #15748
Eventuell auch nochmal ein neues System zum Testen mit Docker aufsetzen und den SMTP Versand dort testen.
Wir nutzen zum testen auch ein zweites Otobo mit den Daten aus einem Backup.
Gruß Marcel
-
20. Oktober 2023 um 12:06 Uhr #15750
Das ist in der Tat sehr komisch. Da braucht es eventuell weiteren Support
In der Otobo Weboberfläche im Admin gibt es die SQL Box.
Kannst du da mal eine Abfrage machen, ob die dort ein Ergebnis bringt. Limit mal auf 10 setzen.
select t.tn as TicketNumber, t.title AS Subject from ticket t
Gruß Marcel
-
20. Oktober 2023 um 12:28 Uhr #15751
Hallo Marcel,
das liefert tatsächlich problemlos 10 Tickets mit Nummer und Betreff.
Gruß
Thorsten
-
-
20. Oktober 2023 um 12:38 Uhr #15752
Da scheint die Datenbank noch zu laufen.
Sehen deine Container auch so aus?
sudo docker ps -a
Gruß Marcel
-
20. Oktober 2023 um 12:48 Uhr #15753
das sieht so aus:
der daemon läuft mit Status unhealthy. Da hatte ich durch googlen (vielleicht falsch) erschlossen das dies kein Problem ist (?). Im Vergleich mit deinem fällt mir aufjedenfall gerade die fehlenden Port-Einträge auf dem web_1 Container auf.
-
20. Oktober 2023 um 13:19 Uhr #15754
kurzer nachtrag, das obigen war das Resultat von docker ps, docker ps -a liefert:
-
-
20. Oktober 2023 um 13:21 Uhr #15755
Nutzt ihr https oder http, wegen dem Nginx Container? Besteht das Problem ggf. seit 5 Tagen?
Wurde hier generell etwas die letzte Zeit verändert?
Ich würde jetzt ein zweites System aufsetzten und schauen, ob da der Daemon Container startet und man die Otobo DB im DB Container sieht.
-
20. Oktober 2023 um 13:29 Uhr #15756
wir nutzen https, allerdings ist hier das Zertifikat abgelaufen – das ist aber schon länger der Fall. (Leider wie so oft ein “geerbtes System” das einige Zeit sich selbst überlassen war).
Das Problem besteht seit mehr als 5 Tagen. Vor 5 Tagen wurde das letzte mal ein Neustart mit des Hosts auf dem die Docker laufen durchgeführt.
-
20. Oktober 2023 um 13:41 Uhr #15757
Da ich mich mit den Docker Containern auch nicht 100% auskenne, bin ich da leider auch mit meinem Rat am ende.
Bitte aber vor großen Änderungen immer ein Backup machen bzw. den Host / VM nochmals sichern.
Eventuell hat im Forum noch jemand anderes mehr Erfahrung.
Gruß Marcel
-
20. Oktober 2023 um 13:47 Uhr #15758
Ok wir schauen mal weiter. Vielen Dank aufjedenfall schonmal für deine Mühen und Tipps Marcel!
-
-
23. Oktober 2023 um 17:46 Uhr #15764
Hallo,
der Daemon ist für den Mailversand unabdingbar. Du kannst mal mit docker restart otobo_daemon_1 versuchen, den neuzustarten (oder mit stop und dann start) und dann ins Log schauen, bspw. docker logs otobo_daemon_1 –since 5m oder so, dann siehst du, was der Container ausspuckt.
Viele Grüße
Stefan -
7. November 2023 um 10:51 Uhr #15828
Hallo Stefan,
danke für die Klärung mit dem daemon, das hat uns auf die richtige Spur gebracht. Jetzt läuft es wieder alles.
-
-
AutorBeiträge
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.