• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

postfix-queue / Queue file write error is still happening

C

ChristopheP

Guest
Hi,

I reported this error in 9.0 , 9.2 and and 9.3 and it was supposed to be fixed in 9.5.

Unfortunatly it's still happening on my server, even if I got half less than before, I still get some and angry customers.

I can provide a network capture of the SMTP conversations that are crashing postfix-queue. I will only mail them to dev as there could be sensitive infos.
 
Any details, samples, error logs, steps to reproduce? I can't send request to developers without details.
 
Hi,

As I said I will only send traces to devs by email as they could contain sensitive data. I have a wireshark trace for you, that will help devs to troubleshoot.

Regards
 
Well here is a thing, about 100 times a day I get an email from the server telling me a message was not delivered to one of my customers due to a "queue file write error". That's it! If you can't go to your developers for that then rest assured, I can go to CPanel!
 
It went worst this night : thousands of queue file write errors in m mailbox.

I proposed devs a network capture of SMTP streams but it looks like they are not interested ....
 
You should see the response I got from igor when I mentioned it in my recent thread about greylisting. Don't think anyone is really interested. I'm certainly going to bring these responses to the attention of thousands of internet professionals. Blatantly calling me a liar in public is utterly unacceptable. Refusing to address the main issue of the post is astounding!
 
Last edited by a moderator:
Hello Plesk team : are you interested in network capture of faulty SMTP connections ? Do you care a minimum about us or the quality of your product ?

Send me a PM with the email of any dev interested in the network capture.
 
Well. Guys, please use following instruction for posting correct report about any Postfix related problems:


0. Read carefully http://kb.odin.com/en/8391
1. Look up time of error message.
2. Find part of DEBUG (How to enable - http://kb.odin.com/en/8391) log /usr/local/psa/var/log/maillog for corresponding time and post it here.
3. Post output of 'df -h' command.
4. Any additional related errors from /var/log/messages


Only such report I can forward to developers for the further investigation!
 
don't follow this KB blindly

I strongly advise everyone to avoid applying this part of the KB:

Monitor and increase disc space in /var and /usr partitions to fix the problem.

Additionally it is recommended changing notify_classes in /etc/postfix/main.cf to forbid postfix writing to admin email

/etc/postfix/main.cf
--->8---
notify_classes = software
---8<---

It is "notify_classes = software, resource" by default.

According to man:

resource
Informs the postmaster of undelivered mail due to resource problems, such as a queue file write error.
software
Notifies the postmaster of mail not delivered due to software failures.

It will just silent errors, but it won't fix them !!!
 
Same with increasing smtpd_timeout and smtpd_proxy_timeout - that will not solve the problem... In some situations the problem will get even worse when increasing this timeouts...
It's possible that the process is running for one hour then - and when you have a lot of running postfix-queue processes you can get a RAM problem and more...

It seems that supressing error messages is a normal procedure for plesk developers...

I guess they did it alredy with the patch in February... After the patch the error messages disappeard - but the problem was exactly the same as before... --> http://forum.parallels.com/showpost.php?p=402544&postcount=21
 
Same with increasing smtpd_timeout and smtpd_proxy_timeout - that will not solve the problem... In some situations the problem will get even worse when increasing this timeouts...
It's possible that the process is running for one hour then - and when you have a lot of running postfix-queue processes you can get a RAM problem and more...

It seems that supressing error messages is a normal procedure for plesk developers...

I guess they did it alredy with the patch in February... After the patch the error messages disappeard - but the problem was exactly the same as before... --> http://forum.parallels.com/showpost.php?p=402544&postcount=21

Did you tried patch from http://kb.odin.com/en/8391 ?
 
I would assume that the version of postfix-queue in the KB is older than that released in Plesk 9.5.1?

I have switched back to that version for now and will report if any notification emails appear.
 
which one should we use ? Official 9.5.1 or the one from the KB ??
 
I can confirm that, for me, using Plesk 9.5.1, but using the postfix-queue from the old update in the KB (http://kb.odin.com/en/8391) has stopped the error.

I had one email about 10 minutes after applying the fix, but since then (over 24 hours ago), I've not had one notification email yet.
 
I can confirm that, for me, using Plesk 9.5.1, but using the postfix-queue from the old update in the KB (http://kb.odin.com/en/8391) has stopped the error.

I had one email about 10 minutes after applying the fix, but since then (over 24 hours ago), I've not had one notification email yet.

OK, so after the 9.3 patch, I have still had queue write error emails - but they ar now few and far between.
Going from 50-60 per day down to 1 or 2.

I am, though, confused as to why this patch is required for a newer version of Plesk than it was made for - and why there are still a few errors slipping through.
 
Back
Top