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

Written by - 0 comments

Published on - 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:

Mails from OTRS Notifications

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.