-
Posts
-
-
Hallo OTOBO Community,
erst einmal vielen Dank an das gesamte Rother OSS Team, dass ihr euch den allein gelassenen OTRS Usern annehmt.
Ganz großes Tennis!Ich habe letzte Woche zunächst unser Testsystem, und am Wochenende auch unser Produktivsystem von OTRS 6.0.23 auf OTOBO 10.0.10 migriert.
Die Datenbank-Migration des Produktivsystems musste ich zwar über die Bash starten (im Webinterface kam es zu Verbindungsabbrüchen), aber bis auf wenige, schnell lösbare Hürden lief fast alles tadellos, und unser Ticketsystem erstrahlt nun in fröhlichem blau/gelb. :)Jedoch habe ich momentan noch ein verbliebenes Problem:
Einmal pro Stunde bekomme ich eine automatisch generierte Mail mit dem folgenden Betreff:
„OTOBO Scheduler Daemon Cron: GenerateDashboardStats“Der Inhalt der Mail ist folgender (diese Zeile wiederholt sich 4 Mal):
„Use of uninitialized value in hash element at /opt/otobo/Kernel/System/Stats.pm line 3223.“Ich kann mit diesem Fehler ehrlich gesagt nicht viel anfangen, und die Dashboard Stats/Grafiken scheinen einwandfrei zu funktionieren.
Was könnte die Ursache sein, und was kann ich unternehmen, um diesen Fehler abzustellen?
Besten Dank und Gruß
Matthias -
Leider komme ich bei diesem Problem immer noch nicht weiter.
Eventuell liegt es ja an der Version einer der installierten Pakete.
Ich habe eine Standard-Installation (kein Docker) unter Ubuntu Server 20.04 laufen.
Folgend die Versionen der einzelnen Pakete:Required packages:
o Archive::Tar.....................ok (v2.32)
o Archive::Zip.....................ok (v1.67)
o Date::Format.....................ok (v2.24)
o DateTime.........................ok (v1.51)
o DateTime::TimeZone.............ok (v2.38)
o Convert::BinHex..................ok (v1.125)
o DBI..............................ok (v1.643)
o Digest::SHA......................ok (v6.02)
o LWP::UserAgent...................ok (v6.26)
o Moo..............................ok (v2.003006)
o namespace::autoclean.............ok (v0.29)
o Net::DNS.........................ok (v1.22)
o Net::SMTP::SSL...................ok (v1.04)
o Sub::Exporter....................ok (v0.987)
o Template::Toolkit................ok (undef)
o Template::Stash::XS..............ok (undef)
o Time::HiRes......................ok (v1.9760)
o Try::Tiny........................ok (v0.30)
o URI..............................ok (v1.71)
o XML::LibXML......................ok (v2.0134)
o YAML::XS.........................ok (v0.81)
o Unicode::Collate.................ok (v1.27)Recommended features for setups using apache:
o ModPerl::Util....................ok (v2.000011)
o Apache::DBI......................ok (v1.12)
o Apache2::Reload..................ok (v0.13)Database support (installing one is required):
o DBD::mysql.......................ok (v4.050)Various features for additional functionality:
o Encode::HanExtra.................ok (v0.23)
o Net::LDAP........................ok (v0.66)
o Crypt::Eksblowfish::Bcrypt.......ok (v0.009)
o XML::LibXSLT.....................ok (v1.99)
o XML::Parser......................ok (v2.46)Features enabling communication with a mail-server:
o Net::SMTP........................ok (v3.11)
o Mail::IMAPClient.................ok (v3.42)
o Authen::SASL.....................ok (v2.16)
o Authen::NTLM.....................ok (v1.09)
o IO::Socket::SSL..................ok (v2.067)Optional features which can increase performance:
o JSON::XS.........................ok (v4.02)
o Text::CSV_XS.....................ok (v1.41) -
Hallo Matthias,
das ist mitten in einem relativ abstrakt gehaltenen Code-Abschnitt, deswegen bin ich mir nicht 100% sicher, aber wenn ich mich grad nicht verguckt hab, ist irgendeiner der Statistiken vmtl durch die Migration fehlerhaft konfiguriert. Und zwar sieht es mir so aus, dass dort für irgendeines der Attribute in den Y-Werten ein Key gesetzt ist, der ungültig ist (also z.B. eine Queue, die nicht mehr existiert – vmtl etwas weniger relevantes…). Um nicht alle Statistiken händisch durchgehen zu müssen (wenn du die Y-Werte öffnest und einmal anklickst, sollte das an der Stelle dann eigentlich auch irgendwo haken), könntest die Datei /opt/otobo/Kernel/System/Stats.pm öffnen und über Zeile 3223 folgendes einfügen (ich kopier einen kleinen Block, damit du den Kontext hast):
if ( !$ArraySelected[1] ) {
print STDERR "$Param{StatID}: $Key\n"; # <- Das hier zum debuggen
$ValueSeries{ $ArraySelected[0]{Values}{$Key} } = { $ArraySelected[0]{Element} => $Value0 };
next KEY;
}Dann kannst du danach auf der shell folgendes ausführen (als otobo-user):
cd /opt/otobo/; bin/otobo.Console.pl Maint::Stats::Dashboard::GenerateDas sollte hoffentlich ein paar Hinweise geben, dann. (Falls du am Code nicht rumspielen willst, kannst du obiges auch mit –number ausführen und dann die Statistiken so durchgehen um zumindest zu gucken, welche es ist.)
Ich hoffe das hilft, viele Grüße, Sven
Edit: Ach, dieses Code-Plugin hier ist wirklich…suboptimal… Ich lass es jetzt so, wie es nach dem zweiten Editieren rauskommt – mal gucken, was er diesmal draus macht, ich hoffe es ist lesbar.
-
Hallo Sven,
Dein Hinweis auf die mögliche Ursache war ein Volltreffer.
Ich habe die Y-Werte aller Dashboard-Stats einmal aufgerufen und neu gespeichert.
Dies waren insgesamt nur 5 – also ein überschaubarer Aufwand.
Zwar sind mir dabei keine Unregelmäßigkeiten aufgefallen, aber das Problem ist seitdem tatsächlich behoben.Leider habe ich erst anschließend die Debug-Zeile in die Stats.pm eingefügt und konnte somit natürlich auch beim Ausführen in der Bash keine Fehler mehr entdecken.
Hier hätte ich vermutlich sofort gesehen, an welcher Stelle es geklemmt hat.Aber das wichtigste ist:
Dank Deiner Hilfe habe ich jetzt eine tadellos funktionierende OTOBO-Installation.
Vielen Dank!!Das Code-Plugin ist tatsächlich nicht der Burner, aber die relevanten Informationen sind ja immerhin angekommen. ;)
Besten Dank und Gruß
Matthias
-
- You must be logged in to reply to this topic.