• 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/master ............Connection refused

xsaver

New Pleskian
Hello,

Plesk 11.5.30 Debian 7.5

After upgrading to Postfix 2.11.0, I see the the following entries minute by minute in my /var/log/mail.warn (/opt/psa/var/log/maillog).

postfix/master[13441]: warning: master_wakeup_timer_event: service qmgr(public/qmgr): Connection refused
postfix/master[13441]: warning: master_wakeup_timer_event: service pickup(public/pickup): Connection refused

The uncomment entries in /etc/postfix/master.cf are

# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)

smtp inet n - - - - smtpd
pickup unix n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr unix n - n 300 1 qmgr
#qmgr unix n - n 300 1 oqmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache

maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)

ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe
flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman unix - n n - - pipe flags=R user=list:list argv=/usr/lib/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient}


plesk_virtual unix - n n - - pipe flags=DORhu user=popuser:popuser argv=/usr/lib/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p /var/qmail/mailnames
pickup fifo n - - 60 1 pickup
plesk_saslauthd unix y y y - 1 plesk_saslauthd status=5 listen=6 dbpath=/plesk/passwd.db
qmgr fifo n - n 1 1 qmgr
smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes

submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination

What is wrong ? Need help !
 
Last edited:
I ran into the same exact issue with a fresh 12.x install. I believe there is a bug in the default master.conf file for Postfix.

This line (near the top):

pickup unix n - - 60 1 pickup

Should read:

pickup fifo n - - 60 1 pickup

And the line 2 lines below:

qmgr unix n - n 300 1 qmgr

Should read:

qmgr fifo n - n 1 1 qmgr

They are supposed to be 'fifo' interfaces, not 'unix'.
 
Just for a notice and to deny, that this is a "bug":

The standard configuration of postfix is based on the unix interface usage, but newer operating system will use fifo for "pickup" and "qmgr". As you can see in your "master.cf", Plesk adds the absolute correct usage at the end of the configuration file - the server administrator(s) just have to make sure on their very own, to uncomment the standard configuration, if it doesn't fit the very own system configuration on the server.
Due to the ( false ) standard configuration and additional ( correct ) Plesk modifications, both interfaces will be used, but only the one with errors will be stated in the error - logs. Postfix works as expected, even if a server administrator doesn't modify the master.cf .
 
Just for a notice and to deny, that this is a "bug":

The standard configuration of postfix is based on the unix interface usage, but newer operating system will use fifo for "pickup" and "qmgr". As you can see in your "master.cf", Plesk adds the absolute correct usage at the end of the configuration file - the server administrator(s) just have to make sure on their very own, to uncomment the standard configuration, if it doesn't fit the very own system configuration on the server.
Due to the ( false ) standard configuration and additional ( correct ) Plesk modifications, both interfaces will be used, but only the one with errors will be stated in the error - logs. Postfix works as expected, even if a server administrator doesn't modify the master.cf .
I think I understand something important, what Plesk has done is correct.

I don't see how you can say that. I spun a new VPS today, and the first thing I did was to establish a fully qualified domain name, because the Plesk installation fails otherwise. The 2nd thing I did was to install Plesk with the typical configuration offered by the installer downloaded with wget http://autoinstall.plesk.com/plesk-installer. After the installation ran, I tried sending some smtp mail with an email tester I have. The mail failed with a lot of error messages;

So if I understand, you are saying I am somehow supposed to have the knowledge to use this plesk email solution and not have all these errors.

Where exactly is that knowledge supposed to come from? before you answer, I will tell you where. It is supposed to come from Plesk, it's what we buy it for.


Before you start acting stupid, I want to tell you I understand that no product lives up to what I am talking about but that doesn't mean that is not the job of this software to have ALL these problems ironed out so normal people, with things to do besides stay on top of the latest nuance of email on linux can get our work done with no hassles.

Instead of acting like you and Plesk are all smart, what you should say is what I say to my customers when my products don't work for them because maybe they don't know enough. I say, "I am sorry that I have not built into the product all the features and knowledge you need to make it useful to you in every way. There is no reason why you should have to struggle, because what you are looking for in the software is to bypass all the hassles, and making that software is my job. I apologize for the short comings of mine you have to compensate for." You probably think I am an idiot for saying this to my customers, but they love it that someone is being an realistic with them and they love it that I take responsibility instead laying it on them,

I am sick and tired of technology geeks using the play of "the problem is you don't know enough" instead of your product isn't good enough in that area. No one is saying plesk sucks, but what does suck is that attitude that smart people are stupid. It's a bunch of ****.
 
The KB article didn't work for me, but commenting out those two default statements certainly removed the error message from the logs. Having said that, apart from the error in the logs, I did not have an issue sending or receiving mail on the system (Plesk 12.0 on CentOS 7). It worked fine out of the box.
 
Back
Top