Emails Stuck in Mail Queue

[Darkness7148]

I've noticed there's emails stuck in the mail queue and don't seem to be going anywhere. The top two are to me and I didn't get alerts for those threads either.

Emails surely shouldn't be taking this long to send. It's active forum so it should have triggered. Doesn't seem to be any issues with the Sending Test Email either.

You cannot view this attachment.

Running. SMF 2.1.6

[Doug Heffernan]

Was there any changes/modifications done to the forum recently?

[Illori]

is the forum sending out any emails?

[Darkness7148]

is the forum sending out any emails?

I checked the Mail Delivery Report in WHM and emails are sending okay. I can't be sure they're from the forum though. I'll have to monitor the list.

Was there any changes/modifications done to the forum recently?

I upgraded to 2.1.5 on Wednesday morning and this started happening. I don't check the Mail Queue that often so could be a coincidence.

I did change my PHP version from 8.1 to 8.3 after I upgraded to 2.1.5 given that you said it was compatible with 8.4.

This error appeared in the Error log after I upgraded to SMF 2.1.5.

Guest
 https://www.avpgalaxy.net/forum/cron.php
 /home/avpgalax/public_html/forum/Sources/ScheduledTasks.php (Line 873)  Backtrace information

Type of error: Cron
Error messageSelect
2: Undefined array key "mail_failed_attempts"

Edit: Just received the top two messages in my emails now.

[Doug Heffernan]

I upgraded to 2.1.5 on Wednesday morning and this started happening.

In the meantime there has been another version released, 2.1.6. Can you update your forum to it and see if it would help?

[Darkness7148]

I already did that. I upgraded as soon as it came out.

[gkawa]

I'm looking at the same problem. It's not a mail server problem. The Send test works, but I think it's a direct call to the send function and it's not using the mail queue. The mail queue is the problem.
I tried inserting a task in the queue manually, it stays there. Forcing the queue doesn't work. One thing I noticed is that the id_mail field changes every time the queue is processed. It's as if the task is attempted and re-entered into the queue. I don't see anything in the error log.

The forum was updated this week to 2.1.5 and 2.1.6 a couple of days after that. Everything went fine. There was a weird error in the log, calls to subs-admin.php with references to non-existing files. Unfortunately, I deleted them. I thought it was just something temporarily broken during the update. It didn't happen again since.

The forum has little movement, so I can't say if all mail tasks are failing or when the problem started. I'll keep looking into it and let you know if I find anything.

[Liviu Lalescu]

I am facing the same problems: the notification emails are delayed many hours and send queue is sometimes locked. The test email works, and notification for a new user again works.

[KittyGalore]

Can confirm this is happening for me also.

[gkawa]

After a couple hours, the queue is empty. So, it's working, just delayed.

[gkawa]

I set a trigger on Insert that inserts into a log table, same structure as smf_mail_queue.
I have no idea what I'm looking for, but maybe someone can make sense out of it. What I see is that the queue is processed and all rows are reinserted into it with new id_mail values.
I wonder if it's about the time each message spends in the queue or the number of times it's processed before it goes out.

[gkawa]

I can confirm the queue is working; it's just delayed. I forgot to put a time control on the new log table. But the first three messages went out after 30-something loops. 30, 33, 34. I think the last one went around more cycles because it was already there when I set the log. I'll add a timestamp to the log and add some more messages to check.

[shawnb61]

In 2.1.5, I know there were changes to mail queuing & error handling.  Some mail transports are changing their behavior & becoming more tweaky.  In many instances, emails are just getting dropped.

Now, if errors are encountered, emails are no longer dropped, they stay in the queue & are retried at a later time (which I think is configurable).

So...   We should be seeing fewer/zero straightup dropped mails.  But...  We should be seeing more queued emails & delays.

https://github.com/SimpleMachines/SMF/pull/7788
https://github.com/SimpleMachines/SMF/issues/7787

It may need some tweaking.

[marcosbr]

envia horas atrasado

sends hours late

[gkawa]

In 2.1.5, I know there were changes to mail queuing & error handling.  Some mail transports are changing their behavior & becoming more tweaky.  In many instances, emails are just getting dropped.

Now, if errors are encountered, emails are no longer dropped, they stay in the queue & are retried at a later time (which I think is configurable).

So...   We should be seeing fewer/zero straightup dropped mails.  But...  We should be seeing more queued emails & delays.

That's what I was thinking when I saw that the messages were being re-queued. But I think something else is going on. I assume that the strategy is to select all the queue, and invoke whatever function is doing the sending of the message for each row. Then, re-queue is something goes wrong. I guess the send test is calling the same function. So, I tried many times forcing the processing of the queue (Send mail queue now or refreshing the main page) and doing the send test at the same time. The tests always work. It can't be a mail server problem.

Here's a report from the log with timestamp. Number of times it was processed in the queue, time_send (time it entered the mail queue) and last time it was inserted in the log (time when it was actually sent).


The last two showed up while I was testing. The first 8 were delayed between 100 and 108 minutes. I have no idea how the system works, but it seems too precise to be coincidental. Quotes here. Precise means around the same value. The process is asynchronous and depends on the activity in the forum. Although I was refreshing it on purpose, I didn't do it at precise intervals.

Hope it helps to find the problem. I'll let the log run overnight and let you people know if something else shows up tomorrow.