« - »

Local Queue in MDaemon 8.x

Posted on 7 June 2005

Recently we just upgraded our Mail Server to use the latest version of MDaemon, that is version 8.0.2. It worked great with several additional major features. However after running smoothly for two days, we found out that a lot of messages (950+) stucked in the Local Queue :-(.

Initially I thought it was caused by our more restricted process when receiving messages, because we activated the new features in MDaemon for security purposes, such as SPF (Sender Policy Framework), Domain Keys, Spam Assasin 3, etc. But even after deactivating the options, the number of messages in Local Queue keep on increasing :-(.

The next possible reason is the DNS delay, because MDaemon needs to query the DNS extensively for ensuring minimum spam messages. We installed Microsoft DNS Server as a DNS cache-only Server in the same PC, but the problem is still unsolved.

Finally, we found two interesting solutions in the mailing list. First solution is to set the “dns_available” setting to “No” in local.cf file. And the second is to add a system environment variables named “res_nameservers” and fill our DNS Server’s IP Address in it.

We chose the second option and it worked well. Well, for one night <g>; then MDaemon began to stucked with 99% processor usage. Being confused, we did the first option by modifying local.cf file. Guess what ?? MDaemon is back to normal, however we are watching the console window closely <g>.

So if you face the similar problem with your MDaemon installation, at least you can try both the options and see which one is suitable for you :-D.

Popularity: 26% [?]

Komentar dan masukan tentang artikel ini akan sangat bermanfaat bagi semua orang. Silakan isi form komentar di bawah ini. Terimakasih sebelumnya!

14 Responses to 'Local Queue in MDaemon 8.x'

Subscribe to comments with RSS or TrackBack to ' Local Queue in MDaemon 8.x '.

  1. Chad said,

    on October 7th, 2005 at 2:09 am

    I have the same problem and I can get the local queue to keep up. In the middle of the day when email is heavy, the local queue gets backed up with a few hundred messages. The CFEngine.exe has very high CPU usuage. I can’t find a solution. This has just started happening in the last two days and I have been using MDaemon for years.

  2. Greg said,

    on February 2nd, 2006 at 12:21 am

    This also has been happening to me. I found that it would start sometime after closing hours and in the morning the email system would be bogged down. I found setting the server to reboot every morning around 5am worked. But then just today it started happeningin the middle of the day. Although a reboot seems to fix the problem, it is only a temporary solution. I can’t be constantly rebooting the server every couple hours. Will try your solutions. Thanks.

  3. hian said,

    on February 2nd, 2006 at 8:50 am

    #Greg: Yes, I agree. Rebooting will not solve the problem permanently in this case. Hopefully this blog helps you a little. Please inform me the result after doing it, and which option you use.

  4. Fred said,

    on February 18th, 2006 at 10:02 am

    I used the “dns_available no” setting in local.cf and it brought my server back up from its knees. I appreciate someone voicing the problem and solution. Many thanks from our community who were adversely affected by this server killer.

  5. hian said,

    on February 18th, 2006 at 1:35 pm

    #Fred: I’m glad it helped you sort out the problem

  6. Fred said,

    on February 19th, 2006 at 12:23 pm

    Darned persistent problem. Like yourselves it was good for 24 hrs then cropped up again. So I went ahead and put in solution #1 as well. So now I have both solutions in place, hopefully that is the ticket!

  7. Gary said,

    on April 24th, 2006 at 8:22 pm

    I was having this problem with version 9.0.. turned out the antispam filter folders were corrupt??? a reinstall over the top sorted it, was as though it was trying to run the emails through the spam filter but couldnt as it wasnt running properly, hence making the local queue stop.

  8. Boba said,

    on November 9th, 2006 at 8:55 am

    Hi all,

    I’m going through this now and was wondering – could someone explain what is involved in “add a system environment variables named “res_nameservers” “?



  9. hian said,

    on November 13th, 2006 at 10:30 am

    #8: Hi Bob, go to Control Panel – System, click Advanced tab, and click Environment Variables button; check in System Variables section. Hope this is clear.

  10. Niks said,

    on February 23rd, 2007 at 10:24 am

    I am also using Mdaemon 9.X also I am not using spamassassin i have disabled that but still the CFEngine.exe takes up 90% CPU load and at times 99% can anyone help withany solution. The server is hosting just one domain with 250 email ids. Its a PIV 2.4 Ghz 2 GB RAM 80 GB X 2 SATA

  11. Rajkumar. T said,

    on April 16th, 2007 at 6:41 pm

    The above mentioned 2 solutions did’nt work for me, i tried using a different SMTP server of my ISP, my problem got solved, the socket Error 10053,10054 is mainly due to the relaying SMTP server.

  12. hian said,

    on April 24th, 2007 at 6:09 pm

    #10: Hi Niks, what version are you using now?? Have you upgraded to the latest version??

    #11: Hi Raj, Socket Error 10053 and 10054 are covered in AltN’s FAQ document (http://www.altn.com/Support/FAQ/)

  13. Turong said,

    on September 27th, 2007 at 12:35 am

    I’ve found an other reason.. just because I’ve out off disk space.. so i’ve got more space then everything will be OK (After restart Mdeamon)

  14. MG said,

    on September 22nd, 2008 at 5:38 am

    A couple years late to this party. However, CFEngine has been running away with RAM for a long time. No matter what we tried, it was killing us. Running MDaemon 6.8.5. Yeah its old, but its paid for!
    Just now turned off Heuristics and Learning functions in the Spam Filter. RAM usage for CFEngine.exe immediately dropped from about a gig to 20 megs. Only time will tell if this really was the culprit, but looks likely at the moment.

Leave a reply