Joachim Schrod wrote:
Sandy Drobic wrote:
Henne Vogelsang wrote:
The reason was too few postfix processes delivering mail, therefor the delivering queue ran full (due to some bug in postfix it seems). This is fixed now.
Usual advice is to use "relay" as transport for outgoing mail, so that incoming smtp connections do not use up all allowed smtp connections or vice versa.
Please allow us the opportunity to learn more about that.
This is caused by the maxproc column in master.cf, isn't it? But I have to confess that I didn't understand it, after reading the documentation.
Sigh, I am just typing this the second time due to power outage. Well, at least I know that my ups is cleanly shutting down all my systems. Just keep in mind that postfix will use the default values if not configured otherwise. The default setting for how many processes are allowed to run simultaneously is set with $default_process_limit. The default is: `postconf -d default_process_limit` = 100.
I looked at my master.cf, and I think the relevant lines seem to be: (I hope that there won't be too much line breaks inserted.)
# service type private unpriv chroot wakeup maxproc command + args smtp inet n - n - - smtpd
That's for incoming TCP connections, AFAIU.
Yes, the command row shows smtpd, the daemon that accepts connections. If a "-" is set instead of a number, then the default is applied, in this case 100.
smtp unix - - n - - smtp relay unix - - n - - smtp
According to my syslog entries, smtp seems to get used for outgoing emails. It is the default value for default_transport which is used for all mails except to $mydestination. The default transport for incoming email is local. The default transport for relayed email is relay.
Yes, smtp is the client program of Postfix that is used to send mails via SMTP. local is a local delivery agent, it does not speak smtp.
I don't understand which service definition in master.cf causes the "use up of allowed smtp connections" for incoming and outgoing emails. Would you please do me the favor and explain that?
I was assuming a mail relay, for example a Postfix relay in front of an exchange server. In that case incoming mail for internal domains will be relayed to the internal exchange server via SMTP, outgoing mails will also be sent via SMTP to their destination servers. Another transport that normally uses the SMTP protocol is the content_filter amavisd-new. If not told otherwise, Postfix won't care, where the smtp clients are sending the mails to, be it to the internal mailserver or the external foreign destination server. A mailinglist server is a special case. If a mailing list has a lot of subscribers, then a few incoming mails are sufficient to generate many thousands of outgoing emails. So Postfix will per default use a max of 100 smtp processes. 5 emails are submitted to the mailing list manager, 10000 emails are generated, and Postfix is using all 100 smtp processes to send mails out. If you are using amavisd-new to first filter the mail, that mail might have to wait for a smtp process to be free to be delivered to amavisd-new. Now, if you are using relay as the default transport for outgoing mails, all 100 smtp processes are available for tranport to amavis or other purposes. The usual reason is, that the mailgateway is using relay as transport to send mails to the internal server and smtp for outgoing mails, so that incoming and outgoing mails do not have to fight for a common pool of available smtp processes to be delivered. They each have their own maxproc setting. As I said, a mailinglist server is a very special beast, and if you have several busy mailing lists with lots of subscribers each, you can have a huge incoming or active queue in a very short time. I haven't yet handled a server that has to send a few hundred thousand mails each day (at least). If I remember correctly Henne said that opensuse has about 1800 subscribers with probably 100-150 mails each day. So, just the opensuse list causes about 200.000 mails to be sent each day. Pack on a few more high-volume mailing lists, and you've got one really busy server. Good hardware and a fast internet connection can cope with that, but it still takes a good deal of careful configuration to deal with the spikes of mails. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org