Egoitz Aurrekoetxea wrote:
Yes, adjust the maxproc column in master.cf <http://master.cf> to
adjust the total number of daemons a particular transport can spawn.
If the maxproc column is "-", then default_process_limit is used.
Ok but this couldn't cause that if for example you have 20 messages to
be redirected for a transport (by the queue manager) and only 4
transport proccesses, it couldn't cause timeouts because you process 4
by 4?
No, reducing the maxproc column in master.cf will not create
errors regardless of the number of messages in the queue that
will use that transport.
I say because sometime have suffered unknown mail transport
errors that has fixed increasing for example the number of smtp
instances in master.cf <http://master.cf> <http://master.cf/>
I mean when you do mailq : you view the "unknown mail transport error"
error... I enabled debug that day and it was throwing socket errors, but
it hadn't arrive to socket limits of the OS or descriptor limit, I
remember that -vv was throwing errors about sockets that were closing
and re-spawning (because of max_use I assume)... although I don't
remember it correctly what I wanted to avoid is just this... I want to
say only 4 smtp clientes, 10 amavis transports... and not to be timeouts
or errores like I described...
Your observation is flawed. Adjusting the maxproc column in
master.cf will not create errors, nor will it fix errors
(assuming sane values for maxproc).
Just consider... If the master.cf maxproc column had to be
larger than the number of queued messages you would never be
able to have more than $default_process_limit messages in the
queue. This is obviously false.
--
Noel Jones
