otrs.Daemon.pl DateTime::TimeZone errors flooding OTRS server after system updates

Written by Claudio Kuenzler - 0 comments

Published on September 27th 2022 - Listed in OTRS Linux Perl

---

After system packages were updated with apt on a Debian Buster, all of a sudden a lot of e-mails were received from the OTRS process running on that server:

The content of these e-mails was all the same:

[Timestamp] otrs.Daemon.pl: Loaded DateTime::TimeZone::Europe::Zurich, which is from a different version (2022b) of the Olson database than this installation of DateTime::TimeZone (2021a).

The very same error can also be found in the OTRS logs in /opt/otrs/var/log/Daemon:

root@otrs:/opt/otrs/var/log/Daemon# tail -f SchedulerFutureTaskManagerERR.log
[Fri Sep 23 08:17:11 2022] otrs.Daemon.pl: Loaded DateTime::TimeZone::Europe::Zurich, which is from a different version (2022b) of the Olson database than this installation of DateTime::TimeZone (2021a).
[Fri Sep 23 08:17:11 2022] otrs.Daemon.pl: Loaded DateTime::TimeZone::Europe::Zurich, which is from a different version (2022b) of the Olson database than this installation of DateTime::TimeZone (2021a).
[Fri Sep 23 08:17:12 2022] otrs.Daemon.pl: Loaded DateTime::TimeZone::Europe::Zurich, which is from a different version (2022b) of the Olson database than this installation of DateTime::TimeZone (2021a).
[Fri Sep 23 08:17:12 2022] otrs.Daemon.pl: Loaded DateTime::TimeZone::Europe::Zurich, which is from a different version (2022b) of the Olson database than this installation of DateTime::TimeZone (2021a).
[Fri Sep 23 08:17:13 2022] otrs.Daemon.pl: Loaded DateTime::TimeZone::Europe::Zurich, which is from a different version (2022b) of the Olson database than this installation of DateTime::TimeZone (2021a).
[...]

Research led to a thread in the Znuny community forums (Znuny is a popular fork of OTRS Community Edition), where one of the users mentioned:

Had to stop and start otrs.Daemon.pl after updating to tzdata 2018i-0+deb8u1"

Interesting, that's what could have happened in this situation, too. Taking a closer look at the apt history log:

root@otrs:~# egrep "^Upgrade" /var/log/apt/history.log
Upgrade: libpython3.7-minimal:amd64 (3.7.3-2+deb10u2, 3.7.3-2+deb10u3), libwebp6:amd64 (0.6.1-2, 0.6.1-2+deb10u1), libldb1:amd64 (2:1.5.1+really1.4.6-3, 2:1.5.1+really1.4.6-3+deb10u1), libkrb5-3:amd64 (1.17-3+deb10u1, 1.17-3+deb10u4), [...], libdatetime-timezone-perl:amd64 (1:2.23-1+2021a, 1:2.23-1+2022b), [...], tzdata:amd64 (2021a-0+deb10u1, 2021a-0+deb10u6)

The previous apt-get dist-upgrade definitely installed newer time/date packages. Turns out the running Perl process (otrs.Daemon.pl) got confused with the new version (2022b) rolling in, mismatching the version at the start (2021a).

To restart the process, become the otrs user and then stop the daemon process:

root@otrs:~# su - otrs
otrs@otrs:~$ ./bin/otrs.Daemon.pl stop

Manage the OTRS daemon process.

Daemon stopped

Then start the daemon process again:

otrs@otrs:~$ ./bin/otrs.Daemon.pl start

Manage the OTRS daemon process.

Daemon started

By following the same log file as before (SchedulerFutureTaskManagerERR.log), no more TimeZone errors should be logged anymore.

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.