On 11/13/2013 11:12 PM, List wrote:
On 11/13/13, 11:52 AM, Viktor Dukhovni wrote:
On Wed, Nov 13, 2013 at 11:18:32AM -0600, List wrote:
I am building a script to handle some specific recipients so I will
be using transport to handle their domain. The script may run for a
long period of time (up to 30 seconds) and I am wondering if there
is a way for the script to let postfix know I have received the
message and let it continue on while it is doing it's work?
You'd have to commit the message to an internal queue managed by
the script, and arrange for periodic queue scans... Otherwise,
if the script tells Postfix its done, but it is not done and
crashes, mail is lost.
All of that is too much work, that's what Postfix does well. So
you're better off not doing that. Just let Postfix wait for the
script. If the script is not or disk CPU intensive (spends a lot
of time waiting for responses from remote systems, ...) you can
raise the transport concurrency to allow more copies of the script
to run in parallel.
If you really want your own queue, you can do that of course, but
it is not clear why you would.
The script itself handles persistence of the message. Is postfix even
capable of being configured to hand off a message via the pipe and
return immediately or is it always going to wait for the script to
complete? If that is the case I could always use a bash script that
calls the main script and fork it to a subshell for immediate return.
Is there any specific reason it needs to return before your script can
confirm that the message has been processed ?
There is no limit on the number of outstanding pipe(8) processes, save
your server's resources.
Just make sure to set the maxproc column (the last one before the
program name) in master.cf at least as high as the one for your incoming
messages (and potentially much higher if you deliver to single
recipients, as pipe(8) scripts often must.)
As long as the pipe(8) process is something that is trivially
parallelizable (i.e. doesn't need to access contented resources on the
backend), this will work better than needing to invent a whole new
queueing system outside of postfix just to guarantee message persistence.
If it ain't broke, don't complicate it.
--
J.
