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.
No comments yet.
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Icingaweb Icingaweb2 Influx Internet Java KVM Kibana Kodi Kubernetes LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Office PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder