Possible problem with newer docker version?
Noticed after a reinstall that now mails get stuck for 25 a 45 minutes in the todo folder. Before the exact same configuration worked perfectly with the older docker 1.7.x series. But now it seems that with the 1.9.x there are some DNS / resolution problems.
This triggers qmail from keeping the mails in the Todo folder for a while ( very annoying ) and then delivers after a while. It almost acts like a grey-list...
Comments (4)
-
reporter -
repo owner Clean new installation does not hit the bug, even older seems ok. This happend after some violent container stop? Nevertheless I have add fix to init it will be in next release. i know qmail is sometimes very hard to debug, thanks for your work!
-
reporter No problem. Hope i can save somebody else from spending so much time figuring out the problem.
I know that the system worked perfectly on my original server ( Mint based ). Stopped the server and moved the configuration files over to a Debian server. Reinstalled the docker files using the original creation parameters. And that is when the problem first showed up. I figured that it was because of a difference in docker versions, so tried following that down the rabbit hole. But did not solve the problem ( note: All this used my original data ).
Then tried going back to old versions of the containers, thinking maybe it was a bug that got introduced after my old Mint installation ( and i was pulling the last container on the new debian build ) but after trying every old version, it was still the same.
Then the blind chase took hours and hours. Knew the mails arrived in the query. All the logs showed it arrived, also checked the sending servers log and i visual noticed it arriving. The moment the sending server send it out, it gave that darn 250 Quered message in the logs.
First assumed it was a graylist so hunting that all the time solved nothing. Then hunting configuration changes. Possible DNS problems. And one day i stumbled upon that answer ( using different directory structure ). Some more hunting found the same structure and still the same answer. Tried it ... and bingo.
I was thinking that i can write a email server faster then it took me to find that problem lol
-
repo owner - changed status to resolved
Fixed!
- Log in to comment
Solution found!
For some reason the qmail is missing the trigger pipeline in the recent builds of this software package!
Check /var/qmail/queue/lock/trigger . It should look like this:
stella# ls -l /var/qmail/queue/lock/trigger prw--w--w- 1 qmails qmail 0 Dec 17 21:56 /var/qmail/queue/lock/trigger
The first character "p" in the
ls -l
output means that the file is a named pipe (also called a "FIFO"). If it's a regular file ("-"), doesn't exist, or if the ownership/permissions are wrong, qmail-send won't get an immediate notification when new messages are added to the queue, and it won't process them until it hits its scheduled wake-up time, typically every 30 minutes.It's easy to fix:
mkfifo /var/qmail/queue/lock/trigger chown qmails:qmail /var/qmail/queue/lock/trigger chmod 622 /var/qmail/queue/lock/trigger
Restart your docker and bingo ... instant email delivery. Only took like 10 freaking hours to trace this problem!
Because the trigger pipeline is missing, it only sends out mails every 30 minutes and people can "enjoy" a nasty half hour delay. This bug seems to be present in a lot of versions of the mail server ...