On December 3, 1998 at 05:03, "Damon K. Haley" wrote:
Thu Dec 3 16:29:42 MST 1998
delivering to pipe "/home/tqs/bin/mhonarc_add operations", system error
Not a very useful error message.
When it stops working it seems to leave a directory called mhonarc.lck
somewhere in public_html.
Any ideas on how to fix/troubleshoot this problem?
If you search the MHonArc list archives, the topic about lock file
problems as come up often.
In general, the following usage guidelines should be followed:
o If performing updates as messages arrive, make sure your
system is configured to avoid abnormal termination of mhonarc.
Otherwise, the archive lock may not get releases, causing
subsequent additions to fail. You should also archive the
original incomming messages somewhere so you can recover
from these kinds of errors.
o One alternative is to do batch incremental archive updates.
I.e. New messages are spooled up in a given location.
Then a periodic cron job is run to archive the new messages.
Now, resources like FORCE can be used with reduced risk.
Also, batch updates are the preferred method if dealing with
large archives.
o Another alternative is to shut off LOCK and use something
like Procmail to handling locking. Many people use Procmail
to support dynamic archive updates, and Procmail's locking
capabilites are more robust than MHonArc's.
Note, MHonArc tries its best to remove the lock on a archive.
It even registers signal handlers to try to deal with signals (note,
the signals that cause core dumps are not handled). It appears there
are cases this is not enough. Without knowing exactly what condition
cause mhonarc to leave a lock file around, it is very hard to determine
if mhonarc can be modified to deal with the condition.
BTW, it is known that perl's signal handling has some problems. I
do not know if this may factor into the problem.
--ewh
----
Earl Hood
earlhood(_at_)usa(_dot_)net
<URL:http://www.oac.uci.edu/indiv/ehood/>