Mailing List Archive: Waiting until action finish

Hi all.

I'm reading and reading and ....
I'm looking for aswer for - maybe - simple question but in manual
about exim and/or procmail there is nothing for me (or is too messy
written for me - unfortunately, because of my english - thing so :( )

I've got Debian, Exim, Procmail

Problem is:

(Mails are comming in shorter then 1 second periods.
Every mail has attachment. Goal is to save every attach into the associated
directory which is done by procmails action called in fitted recipe.
Action of recipe of procmail - that every of those mails fit - is done in longer
then 5 seconds.)

!!! How to wait and not filtering thru procmail arriveing mails until the action
of previous one finish. !!!

I've tested

exim -bd -q10s

but doesn't work.
OR maybe does but I do not quite understand its activity so I can't see if
works or not. (I've found something like Exim acting as "runq" but what shold
be done forward ?! - and whether it is the solution !?)

Please help because It is important for me and eny of my better knowing english
coleagues less know informatic problems and can't translate me manual so I could
help myself.

Marek Wysmulek.

---------------------------

Marek Wysmu³ek

On Fri, 7 Jun 2002, Marek Wysmulek wrote:

> (Mails are comming in shorter then 1 second periods.
> Every mail has attachment. Goal is to save every attach into the associated
> directory which is done by procmails action called in fitted recipe.
> Action of recipe of procmail - that every of those mails fit - is done in l=
> onger
> then 5 seconds.)
>
> !!! How to wait and not filtering thru procmail arriveing mails until the a=
> ction
> of previous one finish. !!!

i don't see any other way than putting exim in queue_only mode, then
only delivering one message at a time by hand.

alas, i don't really see the real problem here. ie. why would you need
to wait for the previous delivery to finish. if the attachments go
into different files (think maildir), then there's no need (none i
could think of, and you didn't give any other clue).

--
[-]