On August 10, 1999 at 14:28, "Martin Bialasinski" wrote:
> looks like my box is too slow for the archive size. I occasionally get
> the message, that mhonarc couldn't get the lock in time. So I guess it
> is time for th FAQ advice
>
> NOTE As an archive increases in size, performing updates as a
> message is received takes more processing time. Therefore, for
> large archives, you may need to do updates through a periodic batch
> process (like via cron(8)) to avoid time-out problems from MHonArc.
>
> Hmm, OK. But how do you do this without creating another race
> condition.
The implication is that the time periods setup in a crontab would
be spaced apart enough to insure MHonArc would finish its job before
the next run. MHonArc will still do a lock.
As for where the mail goes until cron kicks of mhonarc, you could
use Procmail (or sendmail directly) to deliver to a spool file
somewhere that mhonarc will process later. You will need a program
that handles the addition to the spool file in a safe way (which
procmail can do).
> Is cp atomic, so I can copy the interim mailbox, process it
cp is not atomic.
> with mhonarc, or will a message coming in during the cp operation be
> lost, or will this cause a file corruption or such?
Mats Dufberg provides one method to get what you want.
Another is to a qmail type delivering scheme.
--ewh
P.S. There are resources to control how long mhonarc waits to create
a lock: LOCKTRIES and LOCKDELAY. Also, you may want to look into
the flock() method of locking (see LOCKMETHOD resource). flock
method is better for dealing with abnormal mhonarc termination.
