Bart Schaefer <schaefer(_at_)zanshin(_dot_)com> writes:
[...]
:0 c
backup/.
[...]
If procmail never closes there then the TRAP doesn' execute maybe?
That's exactly what's happening. The "c" means that procmail is making a
copy of the message; the TRAP won't execute until the "final" delivery.
The message-id is getting logged, although it's only logged once per
message. Why isn't that enough?
Its only that I was looking for some regularity in the log contents.
Normally one printing of a message-id would be plenty. For scripting
purposes I noticed that the m/id printed for all the other recipes
(not the backup recipe) occurs at the end of output for that message.
The script I'm writing requires a beginning indicator in order to
pluck out an entry from beginning to end. My first thougt was the
line just after the occurrence of m/id would be the beginning of the
next section, which would end in that messages m/id.
My awk script will pluck one message worth of log output out of the
log by its message-id. But the `c' flag throws a monkey wrench into
the works. Meaning my snatch/grab might grab a bunch of extraneos
lines by missing the m/id at the backup recipe.
I homed in on message id since it is required to ID a message for
sure. It doesn't have to be at the begining or end of a section
though. If I can identify anything that is a constant start/stop of
the log entries for each message. It will work just as well.
I tried your suggestion:
:0 c
{
:0
backup/.
}
It cause several things to be double printed like this:
procmail: Assigning "EXITCODE=0"
procmail: Executing "formail,-XMessage-Id:"
procmail: Executing "formail,-XMessage-Id:"
Message-Id: <200110290051(_dot_)f9T0p5915862(_at_)reader(_dot_)local(_dot_)lan>
Message-Id: <200110290051(_dot_)f9T0p5915862(_at_)reader(_dot_)local(_dot_)lan>
When the "c" flag appears before a block, procmail forks. In this case
the TRAP will be executed when each procmail process finishes.
However, I don't think there's any guarantee in that case that the two
processes write serially to the log file -- that is, you might get
From/Subject/Folder from one process, then From/Subject/Folder from the
other, and then Message-Id from one, and then Message-Id from the other --
Yup...
so you might have to employ an additional lock file to assure that the
output looks like what you want. Someone will certainly correct me on
this if I'm wrong.
Not sure where to put it. Probably doing it wrong to boot.
Trying:
:0: c
{
:0
backup/.
}
[...]
Makes everthing get written to backup/. but no where else
Trying:
:0: c
{
:0:
backup/.
}
[...]
Causes errors:
procmail: Acquiring kernel-lock
procmail: [19801] Sun Oct 28 18:22:24 2001
procmail: Locking "backup/..lock"
procmail: Error while writing to "backup/_Z1E.g1L37.reader.local.lan"
procmail: Notified comsat:
"reader(_at_)0:/home/reader/projects/proc/spool/cron_misc.
in"
Somehow the m/id gets mangled into the delivery address.
As for where one entry ends and the next begins: The line with the `date`
output will always be the first one resulting from any message delivery.
You probably should be using
LOG="`date`
"
I do have something similar shown in my original post I think
LOG=`date +"%b %d %T %w"`
But it seems it doesn't get printed in a regular dependable way
either.
Is it possible maybe to cause that recipe to print its log messages
somewhere else or not print them at all? Seems the `c' causes the log
to be less organized far as my intended scripting goes.
Can I make the backup recipe log to a different log somehow, yet let
all the others log to a single log.?
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail