Anyone seen anything like this?
running modperl 1.21 on linux with a work around for the corrupted PATH
environment variable issue... perl 5.004_05 ...
This code:
open( MAIL, "| $MAILER" ) || die "can't open $MAILER";
print MAIL <<"EOM";
HELO localhost
ONEX
MAIL FROM: $from
EOM
foreach (split(/,/,$to)) {
print MAIL <<"EOM";
RCPT TO: $_
EOM
}
print MAIL <<"EOM";
DATA
To: $to
From: accounts\@baremetal.com
Subject: $subject
$body
.
QUIT
EOM
close MAIL || die "couldn't close mailer";
is producing the following output when traced:
write(5, "HELO localhost\nONEX\nMAIL FROM: [EMAIL PROTECTED]\n0RCPT
TO: [EMAIL PROTECTED]\n0RCPT TO: [EMAIL PROTECTED]\n0DATA\nTo:
[EMAIL PROTECTED],[EMAIL PROTECTED]\nFrom:
[EMAIL PROTECTED]\nSubject: Warning, tbrown paid an invoice (7851)
and has held virtuals\n\nWarning, tbrown paid an invoice (7851)\nand has
the following held or scheduled held virtuals:\n\nathleteschoice.net -
1999-08-02\n\n.\nQUIT\n0", 411) = 411
close(5) = 0
There's an extra 0 before the two RCPT TO lines, the DATA line, and after
the QUIT line.
Needless to say, the messages aren't getting out when the relevent SMTP
commands are getting corrupted... The "sendmail -bs" technique is usefull
when the return envelope address needs to be specified and can't be
trusted on the command line. (and isn't really the issue here anyway.)
If I kill -HUP the webserver the issue will go away for a while.
Anyone have any ideas? I rewrote a major section of the invoice generation
code to buffer up the output and use one print statement... in that
section it reduced the number of extraneous zeros to one, but that's still
ugly...
The code is "use strict" and perl -w friendly. everything is my()'d and
properly initialized ... That said, those points seem irrelevent, this
looks like something nasty inside the perl or mod_perl guts....
The app was written under mod_perl, and I can post or mail the whole thing
if need be. Unfortunately, it takes a while to get the problem to appear,
although it's constant once it does.
The application does "use CGI;" and proceeds to send all it's normal
output to STDOUT as compared to using $cgi->print or anything funky...
The box is "internal use only" so I can take it apart and rebuild PERL or
whatever, but I'd really rather not have to, since we do use mod_perl on
production servers and the advantage has always been that it is so easy to
setup... (although perhaps not so easy to code for :-)
-Tom
