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.
2025-06-27 17 52 35.png
Running. SMF 2.1.6
Was there any changes/modifications done to the forum recently?
is the forum sending out any emails?
Quote from: Illori on June 27, 2025, 01:02:00 PMis 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. Quote from: Doug Heffernan on June 27, 2025, 01:01:03 PMWas 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.
QuoteGuest
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.
Quote from: Darkness7148 on June 27, 2025, 01:15:26 PMI 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?
I already did that. I upgraded as soon as it came out.
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.
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.
Can confirm this is happening for me also.
After a couple hours, the queue is empty. So, it's working, just delayed.
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.
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.
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.
envia horas atrasado
sends hours late
Quote from: shawnb61 on Yesterday at 06:44:36 PMIn 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).
(https://i.postimg.cc/GH1NJK7J/Untitled.png) (https://postimg.cc/GH1NJK7J)
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.
I'm having the same problem since upgrading to 2.1.5, then 2.1.6. Most annoyingly, new members' activation emails are being delayed.
I made a mistake. The timestamp indicates the last time the message was reinserted into the queue. The message was sent the next time, and I have no record of it. I have to add a delete trigger.
(https://i.postimg.cc/qtJg0c9K/Untitled1.png) (https://postimg.cc/qtJg0c9K)
The first one was still in the queue this morning. We have little to no activity; it wasn't processed since 20:35 last night, and went away in the first try. But the last 2 are still there after 5 tries, and they have more than 10 hours stuck in the queue. I don't think it's relevant; there are daily digests. I added the delete trigger and some more messages to see if I can get more info about it.
I can confirm that it's related to time_sent. I sent another newsletter to a group. I set the time_sent of one message one day back, it got sent immediately. Funny thing, one of the daily digests went with it after 10 hours. I guess the priority matters; those are 26 in priority. I
Almost all the newsletter notifications were sent between 132 and 133 minutes. A very small part of them were in the 110 and 120 range. There was a password reset in the middle that went out in 115 minutes. So, whatever the number is, it's around 2 hours.
The second daily digest took over 800 minutes.
Same issue here.....
anyone having any idea on the root cause - except it is linked to 2.1.6?
I would have liked to add a screenshot, but apparently this isn't possible either.