Eskalations-Mails kein Versand

Tut-Ench-Amun · Post by **Tut-Ench-Amun** » 20 Jan 2010, 15:34

Hallo,

ich habe das Forum schon durchsucht und eine Menge zur Eskalation gefunden, leider funktioniert es nicht. Ich habe laut Handbuch die "GenericAgent.pm" bearbeitet
Auszug:
# -----------------------------------------------------------------------
%Jobs = (

# [name of job] -> send escalation notifications
'send escalation notifications' => {
Escalation => 1,
# new ticket properties
New => {
Module => 'Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue',
},
},
# insert your jobs (see Kernel/Config/GenericAgent.pm.examples)

);
# -----------------------------------------------------------------------
# end of config options

Ein Mailversand vom OTRS System funktioniert, da die Automatischen Antworten (welche ich konfiguriert habe) versendet werden. Leider finde ich im Taskplaner keinen Job für diese Aufgabe und in keinem Log eine Aufschluß über den Fehler. Nach der Dokumentation muss nur in der "GenericAgent.pm" die Auskommentierten Zeilen aktiviert werden. Dies habe ich auch so durchgeführt und zu den einzelnen Queue die Eskalationszeiten definiert. Laut Dashboard funktioniert diese Eskalation auch, aber kein Mailversand.

Wer kann mir noch Hinweise geben für die Fehlersuche. Ich habe leider ein Windows als OS darunter, daher habe ich kein OTRS Systemlog.

Vielen DAnk für die Hilfe

jojo · Post by **jojo** » 20 Jan 2010, 16:09

Anscheinend laufen die Cronjobs nicht? Kommen den Mails ins System?

Der Windows Task Planer wird nicht verwendet!

garwen · Post by **garwen** » 20 Jan 2010, 16:09

Da hat's 2 Zeilen in der pm, die auch dokumentiert sind

Code: Select all

            # notify all agents who selected the queue in "my queues/custom queues"
#            Module => 'Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue',
            # notify all agents who can access the ticket with rw permissions
            Module => 'Kernel::System::GenericAgent::NotifyAgentGroupWithWritePermission',

Bei der Zeile die Du aktiviert hast, werden nur die Agenten informiert, die die Queue als "Meine Queue" in den Einstellungen gewählt haben.

Tut-Ench-Amun · Post by **Tut-Ench-Amun** » 20 Jan 2010, 16:11

Hallo Jojo

Mails kommen ins System, habe es gerade noch einmal getestet. Dieser Task steht auf 10 min.

Tut-Ench-Amun · Post by **Tut-Ench-Amun** » 20 Jan 2010, 16:16

hi garwen,

ich habe die Queue in meinen Queue hinzugefügt bzw. sie waren es. Wir nutzen das System schon produktiv. Wenn Mails in die betroffene Queue kommen, werde ich auch benachrichtigt, nur bei der Eskalationszeit nicht.

Tut-Ench-Amun · Post by **Tut-Ench-Amun** » 21 Jan 2010, 13:10

Hallo,

vielen Dank für die Hilfe, der richtige Hinweis war mit dabei. Ich hatte das StrawberryPerl durch ein anderes ersetzt. Leider habe ich für Cronw nicht die Pfade angepasst. Somit liefen nicht alle Cron-Jobs. Warum nicht alle - keine Ahnung. Nach Anpassung der crontap.txt funktioniert es sauber. Weiterhin ist in der GenericAgent.pl auch noch der Pfad zum alten StrawberryPerl enthalten. ($home/bin/)

Nun funktioniert es so wie ich es möchte...

Danke an die Helfer

Schlumpf · Post by **Schlumpf** » 05 May 2010, 10:58

Hallo,

habe jetzt das gleiche Problem. Früher kamen Eskalations-Emails an, jetzt kommen nur noch Emails bei Eingang eines neuen Tickets und bei Verschieben in eine andere Queue. Die Agenten haben für die Queues volle Rechte.
Ich habe keine Ahnung, was ich verändert haben soll. In der GenericAgent.pm habe ich beide Varianten ausprobiert (Module => 'Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue', und Module => 'Kernel::System::GenericAgent::NotifyAgentGroupWithWritePermission',) und die Rauten vor den Zeilen gelöscht, so wie es im ersten Beitrag auch zitiert ist; das brachte aber auch keinen Erfolg.

Die Cronjobs laufen auch - bei der Eingabe von "crontab -l -u otrs" erhalte ich etliche Zeilen:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/opt/otrs/var/tmp/cron installed on Wed May 5 10:42:50 2010)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# --
# cron/aaa_base - base crontab package

etc.

Was kann ich noch tun??

Viele Grüße
Schlumpf

Schlumpf · Post by **Schlumpf** » 17 May 2010, 08:07

*up*

Kann mir vielleicht doch jemand helfen?? Ich brauche die Eskalations E-Mails hier im Betrieb.. Bitte

Grüße
Schlumpf

tto · Post by **tto** » 17 May 2010, 08:12

Schlumpf wrote: Die Cronjobs laufen auch - bei der Eingabe von "crontab -l -u otrs" erhalte ich etliche Zeilen:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/opt/otrs/var/tmp/cron installed on Wed May 5 10:42:50 2010)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# --
# cron/aaa_base - base crontab package

etc.

Was kann ich noch tun??

...das sieht ein wenig so aus als wuerden einfach nicht alle Cron-Jobs laufen. Sofern in <OTRS_HOME>/var/cron/ alle relevanten Cronjobbeschreibungen vorhanden sind (Dateien OHNE .dist) einfach mal die Cronjobs mittels <OTRS_HOME>/bin/Cron.sh neu laden und dann nochmal schauen.

CU, Torsten

Schlumpf · Post by **Schlumpf** » 17 May 2010, 09:24

Hallo Torsten,

da kommt bei mir folgendes:

Code: Select all

sudo /opt/otrs/bin/cron.sh
root's password:
sudo: /opt/otrs/bin/cron.sh: command not found

/opt/otrs/bin/cron.sh otrs otrs
-bash: /opt/otrs/bin/cron.sh: Datei oder Verzeichnis nicht gefunden

Also einmal mit sudo und dann mit dem OTRS user. Und ja, die cron.sh ist in diesem Verzeichnis.
Da mache ich noch was falsch, oder?

Viele Grüße
Schlumpf

jojo · Post by **jojo** » 17 May 2010, 09:27

probier es mal mit nem großem C

Schlumpf · Post by **Schlumpf** » 17 May 2010, 09:37

Hallo jojo,

Dann bekomme ich schonmal diese Meldung:

Code: Select all

/opt/otrs/bin/Cron.sh stop otrs otrs
Run this script just as OTRS user! Or use 'Cron.sh {start|stop|restart} OTRS_USER' as root!

Entweder haperts nun noch an der richtigen Syntax oder am OTRS-Benutzer. An dem habe ich keine Einstellungen vorgenommen, also sollte es doch standardmäßig otrs otrs sein, oder?

Viele Grüße

jojo · Post by **jojo** » 17 May 2010, 09:38

Als root:

Code: Select all

/opt/otrs/bin/Cron.sh stop otrs
/opt/otrs/bin/Cron.sh stop otrs

Schlumpf · Post by **Schlumpf** » 17 May 2010, 09:41

Da kommt die gleiche Fehlermeldung:

Code: Select all

/opt/otrs/bin/Cron.sh stop otrs
Run this script just as OTRS user! Or use 'Cron.sh {start|stop|restart} OTRS_USER' as root!

jojo · Post by **jojo** » 17 May 2010, 09:43

dann warst Du wohl nicht root

Schlumpf · Post by **Schlumpf** » 17 May 2010, 10:26

Ok, recht gehabt. Es ist noch Montag früh ^^

Jetzt lief das erstmal durch und brachte mir folgende Meldung:

Code: Select all

sudo /opt/otrs/bin/Cron.sh stop otrs
root's password:
/
Cron.sh - start/stop OTRS cronjobs - <$Revision: 1.19 $>
Copyright (C) 2001-2009 xxx, http://otrs.org/
no crontab for otrs
failed

Das sieht trotzdem nicht sehr vielversprechend aus.

jojo · Post by **jojo** » 17 May 2010, 10:32

und was sagt er nach dem Start? Wenn Du mit crontab -u otrs -l prüfst?

Schlumpf · Post by **Schlumpf** » 17 May 2010, 11:02

Da sagt er mir das:

Code: Select all

crontab -u otrs -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/opt/otrs/var/tmp/otrs-cron-tmp.27158 installed on Mon May 17 10:55:01 2010)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# --
# cron/aaa_base - base crontab package
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: aaa_base.dist,v 1.7 2009/02/16 20:35:25 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# Who gets the cron emails?
MAILTO="root@localhost"
# --
# cron/fetchmail - fetchmail cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: fetchmail.dist,v 1.10 2009/02/16 20:53:10 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# fetch every 5 minutes emails via fetchmail
#*/5 * * * * [ -x /usr/bin/fetchmail ] && /usr/bin/fetchmail -a >> /dev/null
#*/5 * * * *    /usr/bin/fetchmail -a --ssl >> /dev/null
# --
# cron/generic_agent - GenericAgent.pl cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: generic_agent.dist,v 1.12 2009/02/16 20:53:10 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# start generic agent every 20 minutes
*/20 * * * *    $HOME/bin/GenericAgent.pl >> /dev/null

# example to execute GenericAgent.pl on 23:00 with
# Kernel::Config::GenericAgentMove job file
#0 23 * * * $HOME/bin/GenericAgent.pl -c "Kernel::Config::GenericAgentMove" >> /dev/null
# --
# cron/generic_agent - GenericAgent.pl cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: generic_agent-database.dist,v 1.8 2009/02/16 20:55:11 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# start generic agent every 10 minutes
*/10 * * * *    $HOME/bin/GenericAgent.pl -c db >> /dev/null
# --
# cron/pending_jobs - pending_jobs cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: pending_jobs.dist,v 1.11 2009/02/16 20:55:11 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# check every 120 min the pending jobs
45 */2 * * *    $HOME/bin/PendingJobs.pl >> /dev/null
# --
# cron/postmaster - postmaster cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: postmaster.dist,v 1.9 2009/02/16 20:55:11 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# check daily the spool directory of OTRS
#10 0 * * * * [ -e /etc/init.d/otrs ] && /etc/init.d/otrs cleanup >> /dev/null; [ -e /etc/rc.d/init.d/otrs ] && /etc/rc.d/init.d/otrs cleanup >> /dev/null
10 0 * * *  $HOME/bin/otrs.cleanup >> /dev/null
# --
# cron/postmaster_mailbox - postmaster_mailbox cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: postmaster_mailbox.dist,v 1.2 2009/02/16 20:55:11 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# fetch emails every 10 minutes
*/10 * * * *    $HOME/bin/PostMasterMailbox.pl >> /dev/null
# --
# cron/rebuild_ticket_index - rebuild ticket index for OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: rebuild_ticket_index.dist,v 1.9 2009/02/16 20:55:11 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# just every day
01 01 * * * $HOME/bin/RebuildTicketIndex.pl >> /dev/null
# --
# cron/session - delete old session ids of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: session.dist,v 1.11 2009/02/16 20:55:11 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# delete every 120 minutes old/idle session ids
55 */2 * * *    $HOME/bin/DeleteSessionIDs.pl --expired >> /dev/null
# --
# cron/unlock - unlock old locked ticket of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: unlock.dist,v 1.10 2009/02/16 20:55:11 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# unlock every hour old locked tickets
35 * * * *  $HOME/bin/UnlockTickets.pl --timeout >> /dev/null

tto · Post by **tto** » 17 May 2010, 11:13

Schlumpf wrote:

Code: Select all

crontab -u otrs -l
# start generic agent every 20 minutes
*/20 * * * *    $HOME/bin/GenericAgent.pl >> /dev/null

...das ist doch schonmal nicht schlecht - wenn jetzt noch <OTRS_HOME>/Kernel/Config/GenericAgent.pm vorhanden und die entsprechende GenericAgent-Definition nicht auskommentiert ist, sollte es funktionieren.

CU, Torsten

Schlumpf · Post by **Schlumpf** » 17 May 2010, 12:59

Die ist vorhanden und in den Config-Options habe ich schon die ursprünglich auskommentierten Zeilen schon geändert. Das sieht jetzt so aus:

Code: Select all

# --------------------------------------------------------------------------------------------------------
# config options
# --------------------------------------------------------------------------------------------------------
%jobs = (

   # [name of job] -> send escalation notifications
   'send escalation notifications' => {
      Escalation => 1,
      # new ticket properties
      New => {
         Module => 'Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue'
      },
   },
   # insert your jobs (see Kernel/Config/GenericAgent.px.examples)

);
# --------------------------------------------------------------------------------------------------------
# end of config options
# --------------------------------------------------------------------------------------------------------

So hatte ich das eigentlich auch gelesen, dass es richtig sein soll. Aber Eskalations E-Mails kommen trotzdem nicht an

Wie gesagt, die E-Mails, dass ein neues Ticket da ist, die kommen ganz normal rein, also kann es an irgendwelchen E-Mail Einstellungen ja nicht liegen.

tto · Post by **tto** » 17 May 2010, 13:16

Schlumpf wrote: So hatte ich das eigentlich auch gelesen, dass es richtig sein soll. Aber Eskalations E-Mails kommen trotzdem nicht an Wie gesagt, die E-Mails, dass ein neues Ticket da ist, die kommen ganz normal rein, also kann es an irgendwelchen E-Mail Einstellungen ja nicht liegen.

...steht in der TicketHistorie ein Eintrag, dass Eskalationsmails versandt wurden? Wenn ja gehen die Mails irgendwo verloren, wenn nein ist das Ticket entweder nicht eskaliert, es muss keiner informiert werden oder etwas anderes ist defekt.

CU, Torsten

Schlumpf · Post by **Schlumpf** » 17 May 2010, 15:25

Also im SystemLog steht zwar Sent agent 'NewTicket' notification to aber das erwartete Sent agent 'Escalation' notification to bleibt aus..

Das heißt also, dass nicht mal der Versuch gestartet wird, die Tickets zu versenden.. Woran kann das liegen?

jojo · Post by **jojo** » 17 May 2010, 15:29

ist das Ticket eskaliert? Hat ein Agent diese Queue unter "Meine Queues"?

Schlumpf · Post by **Schlumpf** » 17 May 2010, 15:43

Eskaliert ist es (in allen 3 Eskalationsarten) und 3 Agenten haben die Queues unter "MeineQueues". Diese kriegen auch die Mails bei Eingang eines neuen Tickets und beim Verschieben. (Wir haben hier nur 3 Agenten und diese haben alle Queues als "MeineQueues" eingestellt).

jojo · Post by **jojo** » 17 May 2010, 16:08

was passiert wenn Du den GenericAgent von Hand ausführst?

Schlumpf · Post by **Schlumpf** » 18 May 2010, 08:13

Habe ich grade mal durchgeführt und an einem vollen Postkorb gemerkt, dass per Hand die E-Mails ohne Probleme versendet werden.

tto · Post by **tto** » 19 May 2010, 11:33

Schlumpf wrote:Habe ich grade mal durchgeführt und an einem vollen Postkorb gemerkt, dass per Hand die E-Mails ohne Probleme versendet werden.

...wird der cronjob nun automatisch gestartet oder nicht? Erfolgen die sonstigen Cron-Job-gesteuerten Aktionen wie z.B. automatische Ticketfreigabe, Setzen eines Folgestatus nach "pending auto*"? Rein mail-technisch sollte es keine Differenzen zwischen manuellem Aufruf und Aufruf via cron-job geben.

CU, Torsten

Schlumpf · Post by **Schlumpf** » 19 May 2010, 13:04

Hallo,

also es geht immer noch nicht automatisch. Nur per Hand hatte es mal geklappt.
Auch die automatische Freigabe, nachdem ich ein Ticket auf "Warten" gesetzt habe, klappt nicht und zeigt mir weiterhin in roter Schrift an z.B.: "Warten bis: -5 Minuten". Es wird also nicht zur Zeit x automatisch wieder freigegeben, sondern bleibt gesperrt.

Also scheinen die Cron-Job Aktionen gar nicht zu gehen hier, oder? Wie kann ich das ändern? ^^

Ciao

tto · Post by **tto** » 19 May 2010, 15:11

Schlumpf wrote: Auch die automatische Freigabe, nachdem ich ein Ticket auf "Warten" gesetzt habe, klappt nicht und zeigt mir weiterhin in roter Schrift an z.B.: "Warten bis: -5 Minuten". Es wird also nicht zur Zeit x automatisch wieder freigegeben, sondern bleibt gesperrt.

Also scheinen die Cron-Job Aktionen gar nicht zu gehen hier, oder? Wie kann ich das ändern? ^^

aha - da haben wir es - kann es sein, dass $HOME des Nutzers unter dem der Cronjob laeuft nicht das OTRS-Verzeichnis ist? Aenderbar ist das durch korrektes Setzen des HOME-Verzeichnisses oder durch Anpassen der Cron-Job definitionen in <OTRS_HOME>/var/cron/<Dateien ohne .dist>. Ersetze dort einfach alle $HOME durch den tatsaechlichen Pfad und lade die Crontab neu.

CU, T.

Schlumpf · Post by **Schlumpf** » 20 May 2010, 07:48

Hab gestern noch alle $HOME's in /opt/otrs/ umgeändert und danach die Crontab neugestartet wieder mit /opt/otrs/bin/Cron.sh stop otrs und das ganze noch mit start.
Leider kommen immer noch keine Eskalationsmails und bei Erreichen der Wartezeit ist das Ticket auch weiterhin gesperrt.

freundliche Grüße

tto · Post by **tto** » 20 May 2010, 09:04

Schlumpf wrote:Hab gestern noch alle $HOME's in /opt/otrs/ umgeändert und danach die Crontab neugestartet wieder mit /opt/otrs/bin/Cron.sh stop otrs und das ganze noch mit start.
Leider kommen immer noch keine Eskalationsmails und bei Erreichen der Wartezeit ist das Ticket auch weiterhin gesperrt.

...irgendetwas stimmt mit der crontab oder der Umgebung in der diese aufgerufen werden nicht. Das ist via Forum schlecht zu analysieren. Am besten mal im syslog schauen. EinProblem im OTRS wuerde ich aber ausschliessen, da ein manueller Aufruf funktioniert. Ggf. nochmal mit genau den Aufrufen aus der crontab gegenpruefen, ansonsten ist mein Remote-Latein am Ende.

CU, T.

Schlumpf · Post by **Schlumpf** » 20 May 2010, 09:33

Habe gerade nochmal die GenericAgent.pl per Hand gestartet. Da kamen die Eskalationen wieder. Allerdings hat er das gesperrte wartende Ticket dabei auch nicht freigegeben..

Was ich nicht verstehe ist vor allem, dass es schonmal automatisch ging (zumindest die Eskalationsmails - ob das Freigeben ging, weiß ich nicht).

Grüße

Znuny Open Source Ticketsystem