Hallo Martin, danke für deine Antwort. Ich habe otrs erfolgreich geupdated, das Problem wurde dadurch allerdings nicht behoben. Daher habe ich mal ein bisschen Log-Dateien durchwühlt. In /var/log/messages steht folgende Fehlermeldung: "... user.err OTRS-otrs.Scheduler-01[4129]: [Error][main::_AutoStop][Line:678]: Can not write into the PID file:'/opt/otrs/var/run/scheduler.pid'! Permission denied" Daraufhin habe ich entdeckt, dass das Verzeichnis /opt/otrs/var/run/ die Berechtigungen root:root hat. Daher ist es nicht verwunderlich, dass der otrs-User nicht die Datei /opt/otrs/var/run/scheduler.pid anstarten kann. Ich finde es bloß irritierend, dass das Verzeichnis zumindest auf unseren beiden Systemen root:root gehört. Ich werde das jetzt mal auf otrs:www umstellen. Für mich stellen sich daher folgende Fragen: 1. Könnte diese Anpassungen zu Problemen führen? 2. Kannst du dir erklären warum die Berechtigungen so gesetzt sind? Grüße Nils ----------------------------

Martin Gruner hat am 13. Oktober 2014 um 10:57 geschrieben:

Hallo Nils,

hast du die Möglichkeit auf die aktuelle 3.3 zu updaten? Da haben wir von einem rc-Skript auf einen cron-Watchdog umgestellt, der den Scheduler bei Bedarf startet und somit sicherstellt, dass er läuft, auch wenn zwischendurch z. B. mal die DB down war und sich der Scheduler daraufhin beendet hat.

Herzlichen Gruß, Martin

Am 10.10.14 um 09:24 schrieb Nils Haug:

...

Hallo zusammen,

wir setzen bei uns in der Firma schon seit mehreren Jahren OTRS ein. OTRS ist auf einem SLES11 SP3 Server und einem weiteren Testsystem in einer KVM-Maschine installiert. Es wird die OTRS-Version 3.3.5 eingesetzt. Seit einiger Zeit (könnte auch mit dem Update zusammenhängen) haben wir nun bei beiden OTRS-Systemen das Problem, dass der otrs-scheduler nach einer bestimmten Zeit oder Events nicht mehr läuft. Ein Auslöser ist der reboot des Systems, es muss aber noch weitere geben. Ich bekomme dann auf der Weboberfläche folgende Warnung: "Scheduler-Prozess ist registriert,scheint aber nicht zu laufen" Wenn ich auf diese klicke werde ich gefragt, ob ich den Scheduler neustarten möchte. Bejahe ich diese Frage ändert sich der Status nur dahingehend dass nun gesagt wird, dass der Scheduler nicht läuft :(

Wenn ich den otrs-Dienst per CLI neustarte, kommt folgende Fehlermeldung: Starting OTRS Scheduler Service... ERROR: OTRS-otrs.Scheduler-01 Perl: 5.10.0 OS: linux Time: Thu Oct 9 16:36:41 2014

Message: NOTICE: otrs.Scheduler.pl is registered on the DB, but the registry has not been updated in 90 seconds!. The register will be deleted so Scheduler can start again without forcing

Traceback (13174): Module: main::_AutoStop (unknown version) Line: 592 Module: /opt/otrs/bin/otrs.Scheduler.pl (unknown version) Line: 239

In einem Forum hatte ich gelesen, dass vermutlich in solchen Fällen ein runlevel-Skript benötigt wird. Daher habe ich das vorhandene Skript versucht anzupassen und unter /etc/init.d/otrs-scheduler-linux abgelegt. Leider ohne Erfolg. Das rc-Skript hänge ich mal als Anhang an.

Ich vermute es handelt sich um ein Berechtigungsproblem. Denn wenn ich den Scheduler als root durch folgende Kommandos neustarte, verschwindet die Fehlermeldung auf der Weboberfläche:

/opt/otrs/bin/otrs.Scheduler.pl -a stop -force/opt/otrs/bin/otrs.Scheduler.pl -a start

Vielleicht hängt es aber auch mit der DB (mysql v. 5.5.1) zusammen. Das Update von mysql war etwa zeitgleich mit dem Start des Auftreten des Problems.

Gibt es Erfahrungen, wie ich das Problem lösen kann? Ich bedanke mich schon im Voraus für eure Tipps.

Mit freundlichen Grüßen

Nils Haug

--------------------------------------------------------------------- OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

-- Martin Gruner Senior Developer R&D

OTRS AG Bahnhofplatz 1a 94315 Straubing

T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/

Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel

Service Desk-Professionalität auf höchstem Niveau – OTRS 3.4 wird zu OTRS 4! – Jetzt Beta-Version testen! http://www.otrs.com/otrs-4-beta-mit-ultra-flachem-design-und-uberarbeitetem-... --------------------------------------------------------------------- OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

Hallo Martin, danke für den Hinweis. Diesen Schritt (7.) hatte ich beim Minor-Upgrade und auch davor übergangen, weil hier nur die Rede von Installationen per Tarball ist: http://otrs.github.io/doc/manual/admin/3.3/de/html/upgrading.html 7. Setzen Sie die Datei-Berechtigungen. wenn der Tarball benutzt wird, führen Sie shell> cd /opt/otrs/ shell> bin/otrs.SetPermissions.pl Nachdem ich das Skript otrs.SetPermissions.pl mit den ausgefüllten Parametern aufgerufen habe, läuft nun wieder alles ordnungsgemäß. Ich gehe davon aus, dass die Berechtigungen bei einer RPM-Installation normalerweise korrekt gesetzt werden. Warum dies bei mir nicht der Fall war, kann ich leider nicht mehr nachvollziehen. Vielen Dank für die Unterstützung und Tipps Liebe Grüße Nils ----------

Martin Gruner hat am 16. Oktober 2014 um 20:20 geschrieben:

Hallo Nils,

hm, hast du otrs.SetPermissions.pl verwendet um die Permissions zu setzen? In dem Fall sollte es nämlich nicht auf root:root stehen.

Herzlichen Gruß, Martin

Am 13.10.14 um 14:17 schrieb Nils Haug:

...

Hallo Martin,

danke für deine Antwort. Ich habe otrs erfolgreich geupdated, das Problem wurde dadurch allerdings nicht behoben.

Daher habe ich mal ein bisschen Log-Dateien durchwühlt. In /var/log/messages steht folgende Fehlermeldung: "... user.err OTRS-otrs.Scheduler-01[4129]: [Error][main::_AutoStop][Line:678]: Can not write into the PID file:'/opt/otrs/var/run/scheduler.pid'! Permission denied"

Daraufhin habe ich entdeckt, dass das Verzeichnis /opt/otrs/var/run/ die Berechtigungen root:root hat. Daher ist es nicht verwunderlich, dass der otrs-User nicht die Datei /opt/otrs/var/run/scheduler.pid anstarten kann. Ich finde es bloß irritierend, dass das Verzeichnis zumindest auf unseren beiden Systemen root:root gehört.

Ich werde das jetzt mal auf otrs:www umstellen.

Für mich stellen sich daher folgende Fragen: 1. Könnte diese Anpassungen zu Problemen führen? 2. Kannst du dir erklären warum die Berechtigungen so gesetzt sind?

Grüße Nils

----------------------------

...

Martin Gruner hat am 13. Oktober 2014 um 10:57 geschrieben:

Hallo Nils,

hast du die Möglichkeit auf die aktuelle 3.3 zu updaten? Da haben wir von einem rc-Skript auf einen cron-Watchdog umgestellt, der den Scheduler bei Bedarf startet und somit sicherstellt, dass er läuft, auch wenn zwischendurch z. B. mal die DB down war und sich der Scheduler daraufhin beendet hat.

Herzlichen Gruß, Martin

Am 10.10.14 um 09:24 schrieb Nils Haug:

...

Hallo zusammen,

wir setzen bei uns in der Firma schon seit mehreren Jahren OTRS ein. OTRS ist auf einem SLES11 SP3 Server und einem weiteren Testsystem in einer KVM-Maschine installiert. Es wird die OTRS-Version 3.3.5 eingesetzt. Seit einiger Zeit (könnte auch mit dem Update zusammenhängen) haben wir nun bei beiden OTRS-Systemen das Problem, dass der otrs-scheduler nach einer bestimmten Zeit oder Events nicht mehr läuft. Ein Auslöser ist der reboot des Systems, es muss aber noch weitere geben. Ich bekomme dann auf der Weboberfläche folgende Warnung: "Scheduler-Prozess ist registriert,scheint aber nicht zu laufen" Wenn ich auf diese klicke werde ich gefragt, ob ich den Scheduler neustarten möchte. Bejahe ich diese Frage ändert sich der Status nur dahingehend dass nun gesagt wird, dass der Scheduler nicht läuft :(

Wenn ich den otrs-Dienst per CLI neustarte, kommt folgende Fehlermeldung: Starting OTRS Scheduler Service... ERROR: OTRS-otrs.Scheduler-01 Perl: 5.10.0 OS: linux Time: Thu Oct 9 16:36:41 2014

Message: NOTICE: otrs.Scheduler.pl is registered on the DB, but the registry has not been updated in 90 seconds!. The register will be deleted so Scheduler can start again without forcing

Traceback (13174): Module: main::_AutoStop (unknown version) Line: 592 Module: /opt/otrs/bin/otrs.Scheduler.pl (unknown version) Line: 239

In einem Forum hatte ich gelesen, dass vermutlich in solchen Fällen ein runlevel-Skript benötigt wird. Daher habe ich das vorhandene Skript versucht anzupassen und unter /etc/init.d/otrs-scheduler-linux abgelegt=

-- Martin Gruner Senior Developer R&D

OTRS AG Bahnhofplatz 1a 94315 Straubing

T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/

Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel

Service Desk-Professionalität auf höchstem Niveau – OTRS 3.4 wird zu OTRS 4! – Jetzt Beta-Version testen! http://www.otrs.com/otrs-4-beta-mit-ultra-flachem-design-und-uberarbeitetem-... --------------------------------------------------------------------- OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de