On Nov 5, 2007 6:58 PM, Ben <ben(_at_)benjamin(_dot_)it> wrote:
(Command time limit exceeded: "/usr/bin/procmail")
[...]
In this script that I run, one of the first lines in the code is to
output the date to a temporary file (for debugging purposes) however
when these time limit problems occur, it's as if the script isn't even
ran because there is just no output in this log file
I suggest that you turn on verbose logging in procmail so that you can
see what really is happening, rather than guessing based on the
nonexistent log of this other script.
I have a rule in procmail like this:
:0: /tmp/email-lock
* ^To:(_dot_)*import(_at_)mydomain(_dot_)com
| /usr/local/sbin/emails.pl
The reason why I specify a lock file is because emails.pl will connect
to a database and get some information and then write this information
to another file.
This should be fine, but the only reason you'd need a lock is if the
"emails.pl" program can not be run simultaneously for two different
messages.
Is it possible that if procmail tries to call my script while it's
already running, that it's just hanging there waiting for it to exit?
The lock should prevent overlapping calls to the script, but procmail
always will wait for external commands to exit before proceeding.
Despite its mnemonic of "wait", the "w" flag (that Dallman suggested
using) only affects whether procmail pays attention to the exit status
of the program, not whether it proceeds without waiting.
This sounds like what's happening and would explain it, although I don't
think procmail works this way.
I'm not sure what you mean by "this way." Every message that is
delivered through procmail is delivered by a separate procmail
process, and the only implicit communication that any two procmail
processes have with each other is through the presence of lockfiles;
so in the absence of locking it's quite possible for the same recipe
to be executing in two or more deliveries at once.
Given that you are using locking, you'll forcibly serialize all copies
of procmail that get started. If ten or twenty messages arrive in
rapid succession, they'll line up waiting each in turn to get that
lock, and the sum total of the "few seconds" for each run of the
script might mean that the deliveries that are last in line get timed
out by sendmail.
If you can't fix "emails.pl" such that it doesn't care if it's run
more than once at a time, you might be better off having procmail
place a copy of each message in a temporary mailbox (I suggest using a
directory rather than a flat file), and set up a cron job (perhaps via
the "logrotate" program) to periodically run emails.pl on each of the
files in that directory before removing them.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail