At 16:55 2004-01-21 +0100, Ralph SOBEK wrote:
Isn't this a misnomer? How can procmail have trouble writing
to /dev/null ? These messages have come up since changing to procmail
3.22. I have _not_ noticed them before.
Well, "Error while writing to" is assigned to errwwriting[] (as a grep of
the source will show). grep the source for errwwriting...
misc.c
writeerr() function
procmail.c
a couple of functions.
robust.c:
void opnlog(file)const char*file;
{ int i;
elog(empty); /* flush stderr */
if(!*file) /* empty LOGFILE? */
file=devnull; /* substitute the bitbucket */
if(0>(i=opena(file))) /* error? keep the old LOGFILE */
writeerr(file),syslog(LOG_NOTICE,slogstr,errwwriting,file);
else
rclose(STDERR),rdup(i),rclose(i),logopened=1;
}
Seems appropriate given your other commentary about logfile settings. So,
if you debug in there, you might find that the opena (which is another
function defined in robust.c) might be returning an error when you work
with /dev/null, and as a result, it emits an error message, generic to the
occasion.
If there's a point for a bug in procmail, it'd be that once logopened is
set to one (above), there's nothing that clears it (I checked). So,
undefining LOGFILE (setting it to a blank string, which in turn, the above
code equates to /dev/null), it'll always appear as being opened.
Disclaimer: I'm not a member of the procmail dev team. Nor do I generally
hack procmail, though I'm happy to do so for money.
I also get the message: "/bin/test: /dev/null: cannot create".
That's the result of something that is being called - say, in a condition
line. Take your beef up with /bin/test...
Unfortunately, I cannot really include a log file here! They
quickly grow to kilobytes,
Why not run the rcfile in a SANDBOX, where you can control the
flow? Excerpted log data for a single message is probably VERY manageable.
but the above error messages cannot be
localized. Unfortuanely procmail mixes log streams together if
procmail has children processes.
A good reason to run it under a SANDBOX. You'd at least have a log
sequence for _one_ message, not every message that has passed through your
host between two points in time.
SUGGESTION: when doing VERBOSE logging have the children
processes identify individually identify their output. Getting:
procmail: Error while writing to "/dev/null"
without being able to identify it's preceding statement is quite
disconcerting.
Yea, I think a PID tag would be nifty. But a SANDBOX will generally
simplify things, and requires no changes to procmail (or any utilities
which parse the logfile).
If you really want a PID tag in the logging, then hack the procmail source
and recompile - it's all right there (the pid is even already sitting in a
variable).
One problem that I ran into was not having the same exit
conditions as entry conditions. This would cause LOGFILE and
LOGABSTRACT to be unset, which would cause an error message concerning
/dev/null as above. For example, in the above excerpts, if VERBOSE is
set, then logging is set, but if the exit script resets LOGFILE and
LOGABSTRACT then a /dev/null error message appears.
It would help if you're talking about /etc/procmailrc vs. ~/.procmailrc, if
you said as much. A user generally doesn't need to restore the logabstract
on exit from their procmailrc, this is generally viewed as only being
necessary in /etc/procmailrc, where you want to restore variables to what
the user would expect them to be when their own ~/.procmailrc starts
processing.
Perhaps you could trigger the exit condition on the presence of the SAVE
variables? For that matter, do as I do, and UNSET the SAVE variables (more
truely restoring the variable set to what the user would expect).
Is this a bug in procedure 3.22 ?
I wouldn't quite consider it to be one - what you're seeing is a warning
which appears to be coming about because you're redefining a variable under
the wrong condition. I see it as something you wouldn't see in 3.22 if
your _rcfile_ didn't have a bug in it. <g>
Any help would be appreciated. If somebody wants to peruse a
500k logfile then I could make it available on the web.
Yea, right. SANDBOX. Makes it a LOT easier to diagnose stuff, and you
don't get volumes of log data unless you run volumes of messages at something.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail