Fresh Install- Mail Queue Issues

[redbaron73]

Rather than migrate our older OTRS to ZNUNY, we have elected to do a fresh LTS installation on new equipment.

The system is setup and running the cron jobs, and has 4 tickets in the system, with no messages being generated, meaning an idle installation.

What is happening is that after about 24 hrs of running, the system starts generating emails such as:

Error: Message sending already in progress! Skipping...

These messages end up filling the mail queue rather quickly. The resolution has been to manually force the send by using:

bin/otrs.Console.pl Maint::Email::MailQueue --send --force

A work around would be to schedule a cron job to force send, but that seems to be a rather brute force bandaid, and I would like to know why this is happening.

Happy to provide additional answers, but here is the basic setup of our system:

ZNUNY OS: Debian 12.4
ZNUNY Version: 6.5.5 (LTS)
Outbound Email: using smarthost to our dedicated postfix server.
Inbound Email: POP3 on our dedicated mail server

No other processes are running on the ZNUNY server.

[root]

Hi,

Have you checked the daemon logs? There must be a reason that the MailQueue sent is stuck.

- Roy

[redbaron73]

What I see is a lot of this message:

Code: Select all

 Message: There was an error executing Execute() in Kernel::System::Console::Command::Maint::Email::MailQueue: Error: Message sending already in progress! Skipping...


 Traceback (24290):
   Module: Kernel::System::Daemon::DaemonModules::BaseTaskWorker::_HandleError Line: 53
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Cron::Run Line: 177
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Run Line: 236
   Module: (eval) Line: 332
   Module: main::Start Line: 332
   Module: /opt/otrs/bin/otrs.Daemon.pl Line: 153

ERROR: OTRS-otrs.Console.pl-Maint::Email::MailQueue-73 Perl: 5.36.0 OS: linux Time: Thu Jan 11 16:31:06 2024

I am deleting all SchedulerTaskWorkerERR* files, and rebooting. This way I can find the first message that caused the flood of repetitive messges. I did not do this on prior reboots, so did not have a clean system for testing. This may take 24 hrs to reoccur, so I will post back once I get the logs clean.

[redbaron73]

Cleared the logs and the system ran for almost 48hrs before the daemon started this log.
There are a lot of system emails generated that are the contents of the log, but those emails seem to being only when the dameon failure began.

First log:

Code: Select all

ERROR: OTRS-otrs.Console.pl-Maint::Email::MailQueue-73 Perl: 5.36.0 OS: linux Time: Sat Jan 13 21:10:00 2024

 Message: There was an error executing Execute() in Kernel::System::Console::Command::Maint::Email::MailQueue: Error: Message sending already in progress! Ski
pping...


 Traceback (247225):
   Module: Kernel::System::Daemon::DaemonModules::BaseTaskWorker::_HandleError Line: 53
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Cron::Run Line: 177
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Run Line: 236
   Module: (eval) Line: 332
   Module: main::Start Line: 332
   Module: /opt/otrs/bin/otrs.Daemon.pl Line: 153

ERROR: OTRS-otrs.Console.pl-Maint::Email::MailQueue-73 Perl: 5.36.0 OS: linux Time: Sat Jan 13 21:11:00 2024

[redbaron73]

Since my last post, I changed the outbound mail handler to SENDMAIL from SMTP. I have a locally installed postfix server handling the mail-relay, which shows no errors. My mail queue is climbing with emails that are all containing this text:

Code: Select all

Subject:	OTRS Scheduler Daemon Cron: MailQueueSend

Error: Message sending already in progress! Skipping...

Thus far, the only solution I have is to schedule a cron job to execute

Code: Select all

 bin/otrs.Console.pl Maint::Email::MailQueue --force --send

This is a rather blunt way to resolve, hoping for some enlightment as to what is causing the frequent locking of the mailqueue? I suspect this has something to do with database latency, or other DB failures that are not being trapped. Open to suggestions.

[redbaron73]

As a follow up to this issue, I have succesfully narrowed it down to latency on MySQL server. We use a cloud base SQL server, which must be generating timeouts faster than expected. Moving the SQL server to the local install stabilized the system.