Re: [Mimedefang] Slaves dying unexpectedly with signal 14
- Original Message - Thanks Jan for your response. I inserted this code in near the start, and in the global section, of my mimedefang-filter, and got the error: snip Jan 18 22:27:48 hosta mimedefang-multiplexor[6491]: Slave 5 stderr: Argument at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Loc... isn't numeric in alarm at /etc/mail/mimedefang-filter line 95. Wow, that's very brave. I said UNTESTED and I meant it. I just typed this in as an example... Hey, I did eyeball it to to make sure it wasn't going to recreate my filesystem or turn my MX into a SPAM zombie :) Hmm... it could also be that perl somehow forgot to install the SIGALRM handler... I suddenly recall that that was the case last time this came up. Quick check is: is it solved if you disable embedded perl? If it is, then you can either leave embedded perl off, send a bug report to spamassassin, or try to debug it yourself... Which might get tricky. I turned the embedded perl off on one of my gateways, after a period of time, I started getting the spurious SIGNAL 14's showing up on the MX where I was still running MD with embedded perl, but not the one where embedded perl was turned off. Typically, an email was being processed by one MX which started the SIGNAL 14 errors and tempfailed the message. The email would then try the other MX which would result in the SIGNAL 14's happening on that machine too. My guess, as suggested, is that SpamAssassin and/or one of it's cronies has an issue with signalling and this is perhaps being caused, or exasperated by the use of embedded perl with MD. I will run with embedded perl turned off until the next Spamassassin release. Thanks everyone for your help. Roland ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves dying unexpectedly with signal 14
On Wed, Jan 18, 2006 at 08:37:31PM +1300, Roland Pope wrote:
I posted an email some time back asking about MD slaves that were
unexpectedly terminating with a signal 14. David Skoll mentioned at the time
that it was possibly a perl module generating this signal 14 which was
somehow not being handled and was causing the slaves to die.
At the time, I upgraded a few of the perl modules, and the problem seemed to
go away.
I assume signal 14 is a SIGALRM. If kill -l on your system doesn't show
14) SIGALRM in the output somewhere, then the below is invalid.
Unfortunately, it is back.
Once the errors start occuring, a restart seems to stop it happening for a
time, but eventually, it returns. This error is occuring on two seperate
mail exchangers (Which are running the same software versions).
I am running mimedefang 2.53 under CentOS linux 3.6
Can anyone give me any pointers at all as to how I can go about further
tracking down what is generating these signal 14's?? Can I arm some sort of
signal handler in my filter and generate some sort of trace back?
A traceback from the moment the signal is generated will not be helpful,
since the alarm() call that generated the signal is issued several seconds
before that (that's the whole point of the alarm() call).
If it's a perl module that uses alarm() and then fails to unset it,
you might be able to trace it by inserting something like this (UNTESTED)
use Carp qw(longmess);
my $buzz;
my $mess;
*CORE::GLOBAL::alarm = sub {
my $arg = shift || $_;
CORE::alarm($arg);
if ( $arg == 0 ) {
undef $buzz;
} else {
$buzz = time + $arg;
$mess = longmess;
}
};
# ... somewhere at the beginning or end of your filter code, where you
# are sure there should be no pending alarms going off..
if ( $buzz ) {
warn Alarm set to go off at . localtime($buzz) .
, set by alarm() call at: $mess;
}
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves dying unexpectedly with signal 14
- Original Message -
From: Jan Pieter Cornet [EMAIL PROTECTED]
I assume signal 14 is a SIGALRM. If kill -l on your system doesn't show
14) SIGALRM in the output somewhere, then the below is invalid.
Yes 14 is SIGALRM
If it's a perl module that uses alarm() and then fails to unset it,
you might be able to trace it by inserting something like this (UNTESTED)
use Carp qw(longmess);
my $buzz;
my $mess;
*CORE::GLOBAL::alarm = sub {
my $arg = shift || $_;
CORE::alarm($arg);
if ( $arg == 0 ) {
undef $buzz;
} else {
$buzz = time + $arg;
$mess = longmess;
}
};
Thanks Jan for your response.
I inserted this code in near the start, and in the global section, of my
mimedefang-filter, and got the error:
snip
Jan 18 22:27:48 hosta mimedefang-multiplexor[6491]: Slave 5 stderr: Argument
at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Loc... isn't numeric
in alarm at /etc/mail/mimedefang-filter line 95.
/snip
When I added an 'md_syslog('info',alarm=$arg);' right after the
'CORE::alarm($arg);' statement, I got:
snip
alarm= at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Locker/Flock.pm
line 78 eval {...} called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Locker/Flock.pm line 73
Mail::SpamAssassin::Locker::Flock::safe_lock('Mail::SpamAssassin::Locker::Fl
ock=HASH(0xb0617a0)','/home/cyrus/.spamassassin/auto-whitelist',30,640)
called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/DBBasedAddrList.pm line 72
Mail::SpamAssassin::DBBasedAddrList::new_checker('Mail::SpamAssassin::DBBase
dAddrList=HASH(0xc287378)','Mail::SpamAssassin=HASH(0x9fe2044)') called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/AutoWhitelist.pm line 95
Mail::SpamAssassin::AutoWhitelist::new('Mail::SpamAssassin::AutoWhitelist','
Mail::SpamAssassin=HASH(0x9fe2044)') called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Plugin/AWL.pm line 352
eval {...} called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Plugin/AWL.pm line 351
Mail::SpamAssassin::Plugin::AWL::check_from_in_auto_whitelist('Mail
/snip
Any ideas what could be changed in your sample code to avoid this error?
Thanks
Roland
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves dying unexpectedly with signal 14
On Wed, Jan 18, 2006 at 10:34:24PM +1300, Roland Pope wrote:
From: Jan Pieter Cornet [EMAIL PROTECTED]
I assume signal 14 is a SIGALRM. If kill -l on your system doesn't show
14) SIGALRM in the output somewhere, then the below is invalid.
Yes 14 is SIGALRM
If it's a perl module that uses alarm() and then fails to unset it,
you might be able to trace it by inserting something like this (UNTESTED)
use Carp qw(longmess);
my $buzz;
my $mess;
*CORE::GLOBAL::alarm = sub {
my $arg = shift || $_;
CORE::alarm($arg);
if ( $arg == 0 ) {
undef $buzz;
} else {
$buzz = time + $arg;
$mess = longmess;
}
};
Thanks Jan for your response.
I inserted this code in near the start, and in the global section, of my
mimedefang-filter, and got the error:
snip
Jan 18 22:27:48 hosta mimedefang-multiplexor[6491]: Slave 5 stderr: Argument
at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Loc... isn't numeric
in alarm at /etc/mail/mimedefang-filter line 95.
Wow, that's very brave. I said UNTESTED and I meant it. I just typed this
in as an example...
And indeed my code is flawed :) if the argument is 0 then shift is
false so it takes $_, but that's not the right criterium... alarm uses
$_ if there is no argument, not if there's a false argument... and it
seems any false argument to alarm (not just 0) also disables it... so,
attempt two... still LARGELY untested:
*CORE::GLOBAL::alarm = sub {
my $arg = @_ ? shift : $_;
CORE::alarm($arg);
if ( !$arg ) {
undef $buzz;
} else {
$buzz = time + $arg;
$mess = Carp::longmess;
}
};
/snip
When I added an 'md_syslog('info',alarm=$arg);' right after the
'CORE::alarm($arg);' statement, I got:
snip
alarm= at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Locker/Flock.pm
line 78 eval {...} called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Locker/Flock.pm line 73
Mail::SpamAssassin::Locker::Flock::safe_lock('Mail::SpamAssassin::Locker::Fl
ock=HASH(0xb0617a0)','/home/cyrus/.spamassassin/auto-whitelist',30,640)
called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/DBBasedAddrList.pm line 72
Mail::SpamAssassin::DBBasedAddrList::new_checker('Mail::SpamAssassin::DBBase
dAddrList=HASH(0xc287378)','Mail::SpamAssassin=HASH(0x9fe2044)') called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/AutoWhitelist.pm line 95
Mail::SpamAssassin::AutoWhitelist::new('Mail::SpamAssassin::AutoWhitelist','
Mail::SpamAssassin=HASH(0x9fe2044)') called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Plugin/AWL.pm line 352
eval {...} called at
/usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Plugin/AWL.pm line 351
Mail::SpamAssassin::Plugin::AWL::check_from_in_auto_whitelist('Mail
/snip
Any ideas what could be changed in your sample code to avoid this error?
Well my original code contained a warn, so results like this is exactly
what is needed...
However, looking at this spamassassin code, it seems like there was
already an alarm active the moment M::A::Locker::Flock was called...
unfortunately my code only remembers the last alarm() call with a non-zero
argument... Or...
Hmm... it could also be that perl somehow forgot to install the SIGALRM
handler... I suddenly recall that that was the case last time this came
up. Quick check is: is it solved if you disable embedded perl? If it is,
then you can either leave embedded perl off, send a bug report to
spamassassin, or try to debug it yourself... Which might get tricky.
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Slaves dying unexpectedly with signal 14
Hi All, I posted an email some time back asking about MD slaves that were unexpectedly terminating with a signal 14. David Skoll mentioned at the time that it was possibly a perl module generating this signal 14 which was somehow not being handled and was causing the slaves to die. At the time, I upgraded a few of the perl modules, and the problem seemed to go away. Unfortunately, it is back. Once the errors start occuring, a restart seems to stop it happening for a time, but eventually, it returns. This error is occuring on two seperate mail exchangers (Which are running the same software versions). I am running mimedefang 2.53 under CentOS linux 3.6 Can anyone give me any pointers at all as to how I can go about further tracking down what is generating these signal 14's?? Can I arm some sort of signal handler in my filter and generate some sort of trace back? Any sort of help would be appreciated. The log messages I am getting are as follows: snip Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Slave 4 died prematurely -- check your filter rules Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Reap: Idle slave 4 (pid 10634) exited due to signal 14 (SLAVE DIED UNEXPECTEDLY) Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Slave 4 resource usage: req=44, scans=8, user=14.830, sys=1.360, nswap=0, majflt=10062, minflt=111990, maxrss=0, bi=0, bo=0 Jan 18 19:00:57 hosta mimedefang[6477]: Error from multiplexor: ERR No response from slave /snip Thanks Roland ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves stuck in recipok
On Wed, 5 Oct 2005, David F. Skoll wrote:
What does your filter_recipient function look like?
It is below, just one call to md_check_against_smtp_server. I didn't
check the other smtp server, i was looking for a DNS problem. Even
telnetting to port 25 it'd take 10 seconds or so get get a 220 welcome,
and more than 10 seconds for the mail from and rcpt to to succeed. Really
thought it was DNS, but DNS seemed ok...
The problem cleared up all by itself in the midst of my
troubleshooting...which is scary cause it may happen again at any time,
haha.
ray
sub filter_recipient {
my($recip, $sender, $ip, $host, $first, $helo,
$rcpt_mailer, $rcpt_host, $rcpt_addr) = @_;
$recip =~ /.+\@(.+)?/; # extract domain part (minus angle bracket)
my $domain = $1;
$domain =~ s#[]##g;
if (($domain =~ /^selu.edu$/i) ($domain !~ /^lists.selu.edu$/i)) {
#md_syslog('info', SLU check recip $recip for domain
$domain);
return md_check_against_smtp_server($sender, $recip,
smtp.selu.edu,
mailstore.selu.edu);
}
return('CONTINUE', OK); # accept recipient if dont find relay
}
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ray DeJean http://www.r-a-y.org
Systems EngineerSoutheastern Louisiana University
IBM Certified Specialist AIX Administration, AIX Support
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves stuck in recipok
-ray wrote: It is below, just one call to md_check_against_smtp_server. The internal server was probably stuck, as you discovered... MIMEDefang doesn't implement a timeout when it talks to the other server (except for the connect() call). Regards, David. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves stuck in recipok
On Jan 20, 7:15pm, -ray wrote: } On Wed, 5 Oct 2005, David F. Skoll wrote: } } What does your filter_recipient function look like? } } It is below, just one call to md_check_against_smtp_server. I didn't } check the other smtp server, i was looking for a DNS problem. Even } telnetting to port 25 it'd take 10 seconds or so get get a 220 welcome, } and more than 10 seconds for the mail from and rcpt to to succeed. Really } thought it was DNS, but DNS seemed ok... Is the other server running any DNSBLs? These can cause nasty delays. If it is running DNSBLs, then you should make sure that the external server is whitelisted. }-- End of excerpt from -ray ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] slaves stuck in recipok
All, My md slaves seem to be getting stuck during recipok, hanging, and soon i have no free slaves. They eventually finish but take way too long to keep up with mail flow. Any idea where to start looking for the problem? Spamassassin? 45 B 13256 (recipok [EMAIL PROTECTED]) 46 B 13257 (recipok [EMAIL PROTECTED]) 47 B 13259 (recipok [EMAIL PROTECTED]) 48 B 13342 (recipok [EMAIL PROTECTED]) 49 B 13344 (recipok [EMAIL PROTECTED]) 50 B 13349 (recipok [EMAIL PROTECTED]) 51 B 13350 (recipok [EMAIL PROTECTED]) 52 B 13351 (recipok [EMAIL PROTECTED]) 53 B 13356 (recipok [EMAIL PROTECTED]) 54 B 13378 (recipok [EMAIL PROTECTED]) 55 B 13381 (scan /sendmail/mqueue/MIMEDefang//mdefang-j951iX1t025806) 56 B 13384 (recipok [EMAIL PROTECTED]) 57 B 13389 (recipok [EMAIL PROTECTED]) 58 B 13394 (recipok [EMAIL PROTECTED]) 59 B 13395 (recipok [EMAIL PROTECTED]) [EMAIL PROTECTED] logs]# md-mx-ctrl slaveinfo 53 Slave 53 State Busy PID 13356 NumRequests 77 NumScans 18 Age 1101 StatusTag recipok [EMAIL PROTECTED] ray -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ray DeJean http://www.r-a-y.org Systems EngineerSoutheastern Louisiana University IBM Certified Specialist AIX Administration, AIX Support =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
On Thu, 4 Aug 2005, Eduardo Otubo wrote: nothing found something smells bad in my debian kingdom I just did an install of Debian stable sarge; it worked out-of-the-box, except MIMEDefang is not automatically added to sendmail.m4, what to do about it is described in /usr/share/doc/mimedefang. Debian includes MIMEDefang v2.51, instead of the most current one, however. Bye, -- Steffen Kaiser ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
Josh Graham wrote: I have the problem every once in a while. Usually when my system gets bogged down. Of course it also happened when one of the perl modules I installed didn't play nice with MIME-tools. What are your system stats and are you running Spamassassin? yes i running Spamassassin Anyone know a command to output the versions of perl modules installed? I just know the perl -v command to show the Perl Version But, understand my point: i do a new installation its supposed to work ... but it doesnt!! ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Slaves died prematurely
On Wed, 3 Aug 2005 11:35:38 -0700, Josh Graham wrote Anyone know a command to output the versions of perl modules installed? I added that to the wiki a long time ago: http://www.mimedefang.org/kwiki/index.cgi?PerlModulesINFO Also, Run a mimedefang.pl -features and see if you are missing any prerequisites.. Are you running embedded perl? if so disable that and retest. To add the -l flag to the init script, you can do this (although it woudl be better to add the option to a sysconfig file, but I dont know if debian uises one): open your init-script.. lookk for the line like: daemon $PROGDIR/$prog-multiplexor -p /var/spool/MIMEDefang/$prog-multipl. and add the -l so it now reads like: daemon $PROGDIR/$prog-multiplexor -l -p /var/spool/MIMEDefang/$prog-multipl You might also want to check out the Optimizing MD page on the wiki: http://www.mimedefang.org/kwiki/index.cgi?OptimizingMIMEDefang To help explain what those milter arguments are, you might need to change from the defaults based on your servers load and mail traffic. Jim -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
i'm installing from an synaptic system no prerequisite is missing... BUT i did a mimedefang.pl -features ans somethings are missing :( what can i do to install these things missingthese are things i 've never seen.. :( i guess if i install a new installation of MD and it doesnt work, the problem might be at the sendmail or spamassassin config files? James Ebright wrote: On Thu, 04 Aug 2005 10:51:05 -0300, Eduardo Otubo wrote But, understand my point: i do a new installation its supposed to work ... but it doesnt!! It works just fine, you are obviously doing something wrong during your installation, probably missing a prerequisite, etc. Sounds to me like you do need to do some more RTFM. Jim -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
Eduardo Otubo wrote: i'm installing from an synaptic system no prerequisite is missing... You need to see WHY the slave is dying. You CANNOT see that unless you enable logging of slave's standard error output from the multiplexor. If you're on Debian, that should be enabled, I believe. But check the startup script to make sure it's passing the -l option to mimedefang-multiplexor. Next, check your logs. You should see lines like: mimedefang-multiplexor[pid]: Slave x stderr: Some error message here... Without the above info, there is NO WAY to figure out your problem. Regards, David. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
On Thu, 4 Aug 2005, Eduardo Otubo wrote: i did a mimedefang.pl -features ans somethings are missing :( what can i do to install these things missingthese are things i 've never seen.. :( Can you post the results of that command? ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
MIMEDefang version 2.51 Archive::Zip : yes HTML::Parser : yes HTML::TokeParser : yes Path:CONFDIR : yes (/etc) Path:QUARANTINEDIR: yes (/var/spool/MIMEDefang) Path:SENDMAIL : yes (/usr/sbin/sendmail) Path:SPOOLDIR : yes (/var/spool/MIMEDefang) SpamAssassin : yes Unix::Syslog : yes File::Scan: no HTMLCleaner : no Net::DNS : no Virus:AVP : no Virus:AVP5: no Virus:BDC : no Virus:CLAMAV : no Virus:CLAMD : no Virus:CSAV: no Virus:FPROT : no Virus:FPROTD : no Virus:FSAV: no Virus:FileScan: no Virus:HBEDV : no Virus:NAI : no Virus:NVCC: no Virus:OpenAV : no Virus:SOPHIE : no Virus:SOPHOS : no Virus:SymantecCSS : no Virus:TREND : no Virus:TROPHIE : no Virus:VEXIRA : no Anomy::HTMLCleaner: missing Archive::Zip : Version 1.14 Digest::SHA1 : Version 2.10 File::Scan: missing HTML::Parser : Version 3.45 HTML::TokeParser : Version 2.30 IO::Socket: Version 1.28 IO::Stringy : Version 2.110 MIME::Base64 : Version 3.04 MIME::Tools : Version 5.417 MIME::Words : Version 5.417 Mail::Mailer : Version 1.62 Mail::SpamAssassin: Version 3.03 Net::DNS : missing Unix::Syslog : Version 0.100 Jim McCullars wrote: On Thu, 4 Aug 2005, Eduardo Otubo wrote: i did a mimedefang.pl -features ans somethings are missing :( what can i do to install these things missingthese are things i 've never seen.. :( Can you post the results of that command? ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
On Thu, 04 Aug 2005 11:45:24 -0300, Eduardo Otubo wrote i'm installing from an synaptic system no prerequisite is missing... BUT i did a mimedefang.pl -features ans somethings are missing :( what can i do to install these things missingthese are things i 've never seen.. :( i guess if i install a new installation of MD and it doesnt work, the problem might be at the sendmail or spamassassin config files? Doubtful it is sendmail, sendmail works (you said yourself) without milter enabled. Spamassassin is just a perl module mostly, doubt that is it anyway and since you are using the default config for MimeDefang, your network tests are disabled anyway. I suspect that you _DO_ have missing pre-requisites. Synaptic is just a gui front end for apt-get and apt-get can only find prerequisits that the package builders knew about and planned for, direct dependencies are not the same thing as prerequisites, at least not exactly, even if they are the same much of the time (for instance, Archive::Zip is a pre-req, but MD builds and insytalls just fine without it, some other perl modules are the same way). DEB or RPM packages in this situation are only as good as the person(s) that built them. You want to be completely sure, build it yourself from source (even if you are just building your own package to install). If you must use prebuilt packages, then you probably need to go through the prerequisites in the INSTALL file and install the package for each (assuming there is one). And like David said... all of this is speculation until you enable logging for the slaves (-l) and see what it is failing on. Jim -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
ok, I added the flag [-l] at the multiplexor startup and configured my syslog.conf to log my multiplexor exits. and the error i found is strange. take a look: Aug 4 15:59:03 fefnet119 mimedefang-multiplexor[18851]: Slave 0 stderr: Can't locate object method new via package MIME::Parser::ParanoidFiler at /usr/bin/mimedefang.pl line 5254. after this line the errors are that the slaves died and so on bla bla bla. i went to the mimedefang.pl file, line 5254 and what I found is: my $filer = new MIME::Parser::ParanoidFiler($msgdir); what the fuck?!?!!?!??!?!?!!?!?!?! perhaps my perl must be updated this is the second thing that came to my mind (the first thing is above... :) ) David F. Skoll wrote: Eduardo Otubo wrote: i'm installing from an synaptic system no prerequisite is missing... You need to see WHY the slave is dying. You CANNOT see that unless you enable logging of slave's standard error output from the multiplexor. If you're on Debian, that should be enabled, I believe. But check the startup script to make sure it's passing the -l option to mimedefang-multiplexor. Next, check your logs. You should see lines like: mimedefang-multiplexor[pid]: Slave x stderr: Some error message here... Without the above info, there is NO WAY to figure out your problem. Regards, David. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Slaves died prematurely
Just a thought, have you got more than one version of perl on there, as i've seen it sometimes where the running version is not the version that gets updated (ie 5.6 and 5.8 where 5.8 get's updated but 5.6 is used to run) try locate MIME/Parser.pm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eduardo Otubo Sent: Thursday 04 August 2005 16:50 To: mimedefang@lists.roaringpenguin.com Subject: Re: [Mimedefang] Slaves died prematurely ok, I added the flag [-l] at the multiplexor startup and configured my syslog.conf to log my multiplexor exits. and the error i found is strange. take a look: Aug 4 15:59:03 fefnet119 mimedefang-multiplexor[18851]: Slave 0 stderr: Can't locate object method new via package MIME::Parser::ParanoidFiler at /usr/bin/mimedefang.pl line 5254. after this line the errors are that the slaves died and so on bla bla bla. i went to the mimedefang.pl file, line 5254 and what I found is: my $filer = new MIME::Parser::ParanoidFiler($msgdir); what the fuck?!?!!?!??!?!?!!?!?!?! perhaps my perl must be updated this is the second thing that came to my mind (the first thing is above... :) ) David F. Skoll wrote: Eduardo Otubo wrote: i'm installing from an synaptic system no prerequisite is missing... You need to see WHY the slave is dying. You CANNOT see that unless you enable logging of slave's standard error output from the multiplexor. If you're on Debian, that should be enabled, I believe. But check the startup script to make sure it's passing the -l option to mimedefang-multiplexor. Next, check your logs. You should see lines like: mimedefang-multiplexor[pid]: Slave x stderr: Some error message here... Without the above info, there is NO WAY to figure out your problem. Regards, David. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang This Email Has Been Anti-Virus Scanned ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
On 04/08/05, Eduardo Otubo [EMAIL PROTECTED] wrote: Aug 4 15:59:03 fefnet119 mimedefang-multiplexor[18851]: Slave 0 stderr: Can't locate object method new via package MIME::Parser::ParanoidFiler at /usr/bin/mimedefang.pl line 5254. Well, an update to MD 2.52 wouldn't hurt I'm sure, however... what the ?!?!!?!??!?!?!!?!?!?! No need for the language... perhaps my perl must be updated this is the second thing that came to my mind (the first thing is above... :) ) What version(s) of perl do you have installed? Did you update perl after installing any perl packages, and forget to re-install them? -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
nothing found something smells bad in my debian kingdom Mack wrote: Just a thought, have you got more than one version of perl on there, as i've seen it sometimes where the running version is not the version that gets updated (ie 5.6 and 5.8 where 5.8 get's updated but 5.6 is used to run) try locate MIME/Parser.pm ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves died prematurely
its hard to say, but everything is working good now the bad part is: i dont know what I did to work the last things I did was: - ok, lets update the mimedefang version, I downloaded the last version [.tar.gz] from the official site and compiled it, compiled the MIMEtools - some errors - uninstalled the version i installed from the site (due to some bugs) - reinstalled the .deb version from the debian server repository - everything is working fine. perhaps is the MIMtools new version i installed Well... THANK YOU ALL VERY MUCH WHO HELPED ME TO UNDERSTAND A LITTLE MORE ABOUT THIS MAIL FILTER I'M VERY GLAD TO HAVE YOU LIKE ADMIN PARTNERS THANKS A LOT YOU ALL! David F. Skoll wrote: Eduardo Otubo wrote: something smells bad in my debian kingdom Try removing the Debian package and installing from source from the mimedefang.org site. It's not impossible that the Debian maintainer has broken something. Regards, David. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
15 minutes seems extremely long... I'm curious, could you explain the rational for that time length? I admit, its longer than I've ever considered reasonable. Thanks, -Brenden On Mon, 2004-11-01 at 16:17, David F. Skoll wrote: On Mon, 1 Nov 2004, Button, Shawn wrote: Here's my mc line, I have experimented with bumping up the timeouts to 5 minutes with limited success, I also dropped the F=T line to make sure that mail still came through... Your timeouts are way too low. I recommend 15 minutes for S, R and E. T=S:15m;R:15m;E:15m Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang -- Brenden Conte System Programmer, CCT Rensselaer Polytechnic Institute (518)276-2540 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
On Tue, 2 Nov 2004, Brenden Conte wrote: 15 minutes seems extremely long... I'm curious, could you explain the rational for that time length? I admit, its longer than I've ever considered reasonable. I've see SA take a long time on some messages. My rationale is that if you've already invested resources in scanning mail, it's best to do your utmost to let it finish; otherwise, it will just come back again... and again... Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
Brenden Conte wrote: 15 minutes seems extremely long... I'm curious, could you explain the rational for that time length? I admit, its longer than I've ever considered reasonable. It depends on how large messages you are accepting. If you set limit to say 1 or 10MB, than 15 minutes is way too much. If you set it to 100MB, and you happen to get 90MB ZIP archive, it might take long time for AV to scan it, plus MIMEDefang will also spend considerable time (and memory) to digest it. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
On Tue, 2 Nov 2004, Aleksandar Milivojevic wrote: It depends on how large messages you are accepting. If you set limit to say 1 or 10MB, than 15 minutes is way too much. I don't think so. If you plot scan times on a busy server, you'll see that most are quite short, but there are a small (but significant) number of outliers that can take a very long time to scan -- even for relatively small messages. It drives me crazy :-), but we see it on our server. I think SpamAssassin's massive amount of regexp manipulation is very sensitive to the actual data it scans; the regexp execution time seems almost non-deterministic. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] slaves
I bumped the 3 timeouts up to 15 minutes and it appears, just at a cursory examination, to now have more time outs (about 8 per hour versus about 4 per hour previously). We are going step by step cleaning up spam assassin rules, removing any alternate SA cf files, testing with spamassassin --lint, etc. The crux of this issue appeared only after we upgraded to SA 3.0 and it implemented bayes. We are examining our mimedefang filter...the test option shows that it is appears ok. For some reason mail is still being rejected when the filter times out...is there a way to allow the mail through instead of rejecting it if the filter times out? We removed the F=T flag in the mc but this didn't seem to help. It would at least buy us some time to hunt this down more. We upgraded 2 weeks ago to the latest NAI sigs and the problem appeared to go away. After upgrading last week and this week the problem has seemed to reappear. Whether or not there is a correlation we have been unable to determine. Thanks, Shawn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David F. Skoll Sent: Tuesday, November 02, 2004 9:00 AM To: [EMAIL PROTECTED] Subject: Re: [Mimedefang] slaves On Tue, 2 Nov 2004, Aleksandar Milivojevic wrote: It depends on how large messages you are accepting. If you set limit to say 1 or 10MB, than 15 minutes is way too much. I don't think so. If you plot scan times on a busy server, you'll see that most are quite short, but there are a small (but significant) number of outliers that can take a very long time to scan -- even for relatively small messages. It drives me crazy :-), but we see it on our server. I think SpamAssassin's massive amount of regexp manipulation is very sensitive to the actual data it scans; the regexp execution time seems almost non-deterministic. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] slaves
On Tue, 2 Nov 2004, Button, Shawn wrote: I bumped the 3 timeouts up to 15 minutes and it appears, just at a cursory examination, to now have more time outs (about 8 per hour versus about 4 per hour previously). Did you increase the multiplexor busy timeout as well? MX_BUSY in the standard startup files. For some reason mail is still being rejected when the filter times out...is there a way to allow the mail through instead of rejecting it if the filter times out? We removed the F=T flag in the mc but this didn't seem to help. It would at least buy us some time to hunt this down more. If you hit MX_BUSY, then the mail will be tempfailed regardless of the F=T setting, because that's a policy decision made by mimedefang rather than by sendmail. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
Button, Shawn wrote: For some reason mail is still being rejected when the filter times out...is there a way to allow the mail through instead of rejecting it if the filter times out? We removed the F=T flag in the mc but this didn't seem to help. It would at least buy us some time to hunt this down more. Hm, removing F=T from mc file, rebuilding cf and restarting sendmail should have helped. The only case where it wouldn't help is if client MUA (or connecting MTA) is too impatient and timeouts connection on its end too soon (default in Sendmail is to wait for response 1 hour after it sends lone dot to remote server). If it is limited to only mails from some sites, it might indicate somebody played with these timeouts in his configuration file. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] slaves
Thank you, I will try that as well. We are net well versed in trouble shooting this because it has always worked flawlessly. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David F. Skoll Sent: Tuesday, November 02, 2004 10:17 AM To: [EMAIL PROTECTED] Subject: RE: [Mimedefang] slaves On Tue, 2 Nov 2004, Button, Shawn wrote: I bumped the 3 timeouts up to 15 minutes and it appears, just at a cursory examination, to now have more time outs (about 8 per hour versus about 4 per hour previously). Did you increase the multiplexor busy timeout as well? MX_BUSY in the standard startup files. For some reason mail is still being rejected when the filter times out...is there a way to allow the mail through instead of rejecting it if the filter times out? We removed the F=T flag in the mc but this didn't seem to help. It would at least buy us some time to hunt this down more. If you hit MX_BUSY, then the mail will be tempfailed regardless of the F=T setting, because that's a policy decision made by mimedefang rather than by sendmail. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
David F. Skoll wrote: If you hit MX_BUSY, then the mail will be tempfailed regardless of the F=T setting, because that's a policy decision made by mimedefang rather than by sendmail. I'll just add to this that it is rather trivial to check which part was failing. If mail is tempfailed by MIMEDefang, than sendmail will log only single line that it is tempfailing message: Milter: data, reject=retrun code) If mail is tempfailed by sendmail because MIMEDefang took too long, you'll see these three lines in sendmail logs: Milter (mimedefang): timeout before data read Milter (mimedefang): to error state data, reject=451 4.7.1 Please try again later If MIMEDefang took too long, and sendmail is accepting the mail (since F=T was ommited), you'll see first two lines, and than a line saying that mail was accepted. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] slaves
This is a typical section of the log file that starts with the failure... Nov 2 10:42:03 oslo mimedefang-multiplexor[15811]: Killing busy slave 1 (pid 17209): Busy timeout Nov 2 10:42:03 oslo mimedefang[17903]: Error from multiplexor: ERR Filter timed out - check filter rules or system load Nov 2 10:42:03 oslo sendmail[17902]: iA2HfX9j017902: to=[EMAIL PROTECTED], delay=00:00:30, pri=32632, stat=Please try again later Nov 2 10:42:03 oslo mimedefang-multiplexor[15811]: Slave 1 resource usage: req=68, scans=68, user=74.360, sys=5.590, nswap=0, majflt=43042, minflt=264304, maxrss=0, bi=0, bo=0 Nov 2 10:42:06 oslo mimedefang-multiplexor[15811]: Starting slave 1 (pid 17909) (2 running): Bringing slaves up to minSlaves (2) Nov 2 10:42:34 oslo sendmail[17905]: iA2Hfbdb017905: from=, size=6338891, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA, relay=mc1-s9.bay6.hotmail.com [65.54.163.149] Nov 2 10:42:35 oslo mimedefang.pl[17477]: MDLOG,iA2Hfbdb017905,mail_in[EMAIL PROTECTED],Delivery Status Notification (Failure) Nov 2 10:42:36 oslo sendmail[17911]: iA2Hfbdb017905: [EMAIL PROTECTED] , delay=00:00:54, xdelay=00:00:01, mailer=esmtp, pri=6369132, relay=[192.xxx.xxx.xxx] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aleksandar Milivojevic Sent: Tuesday, November 02, 2004 10:38 AM To: [EMAIL PROTECTED] Subject: Re: [Mimedefang] slaves David F. Skoll wrote: If you hit MX_BUSY, then the mail will be tempfailed regardless of the F=T setting, because that's a policy decision made by mimedefang rather than by sendmail. I'll just add to this that it is rather trivial to check which part was failing. If mail is tempfailed by MIMEDefang, than sendmail will log only single line that it is tempfailing message: Milter: data, reject=retrun code) If mail is tempfailed by sendmail because MIMEDefang took too long, you'll see these three lines in sendmail logs: Milter (mimedefang): timeout before data read Milter (mimedefang): to error state data, reject=451 4.7.1 Please try again later If MIMEDefang took too long, and sendmail is accepting the mail (since F=T was ommited), you'll see first two lines, and than a line saying that mail was accepted. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
Button, Shawn wrote: This is a typical section of the log file that starts with the failure... Nov 2 10:42:03 oslo mimedefang-multiplexor[15811]: Killing busy slave 1 (pid 17209): Busy timeout Nov 2 10:42:03 oslo mimedefang[17903]: Error from multiplexor: ERR Filter timed out - check filter rules or system load Nov 2 10:42:03 oslo sendmail[17902]: iA2HfX9j017902: to=[EMAIL PROTECTED], delay=00:00:30, pri=32632, stat=Please try again later Looking at this, it seems it's MX_BUSY being set too low, just as David pointed out earlier. mimdefang-multiplexor killed the slave, and instructed Sendmail to tempfail the message. Sendmail should have logged another line just after it got 'MAIL FROM', (grep for iA2HfX9j017902 in logs). It will give you an idea for how long MIMEDefang was processing the email, before it gave up. If what David pointed out to you is correct, the time difference will match your current MX_BUSY seting (give or take couple of seconds). Try boosting MX_BUSY to 600 (10 minutes) or even 900 (15 minutes). BTW, don't let huge mails go through SpamAssassin. Anything larger than say 100k isn't likely to be spam, and it will take *really* long time and huge amount of memory for SpamAssassin to digest large emails. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
On Mon, 1 Nov 2004, Button, Shawn wrote: Here's my mc line, I have experimented with bumping up the timeouts to 5 minutes with limited success, I also dropped the F=T line to make sure that mail still came through... Your timeouts are way too low. I recommend 15 minutes for S, R and E. T=S:15m;R:15m;E:15m Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] slaves
Thank you kindly... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David F. Skoll Sent: Monday, November 01, 2004 2:18 PM To: [EMAIL PROTECTED] Subject: Re: [Mimedefang] slaves On Mon, 1 Nov 2004, Button, Shawn wrote: Here's my mc line, I have experimented with bumping up the timeouts to 5 minutes with limited success, I also dropped the F=T line to make sure that mail still came through... Your timeouts are way too low. I recommend 15 minutes for S, R and E. T=S:15m;R:15m;E:15m Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Slaves dying shortly after startup
Looking at the stuff you posted, and seeing that re-installing a basic filter didn't help, my suspicion is that you also modified the memory limits in the startup script and that you're hitting these almost immediately with the full set of SA rules. With the cut-down version, you're OK - but if a largeish message comes in, you may find the filter dying again as it hits the limit. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves dying shortly after startup
Graham Dunn sighed and wrote:: This started happening this afternoon, after I changed mimedefang-filter. When the slaves started dying, I reverted my changes, and restarted, but the problem persisted. I've tried running with the stock suggested-minimum-filter-for-windows-clients filter, same problem. Usually, this means that there's still a change in the mimedefang-filter that was missing. The usual reason that I get this major hiccup is because of some syntactical error (missing semicolon, etc..) Recheck your mimedefang-filter carefully for mistakes in syntax, spelling, etc. Edmund ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves dying shortly after startup
On Mon, Mar 29, 2004 at 05:07:24PM +0800, cc wrote: Graham Dunn sighed and wrote:: This started happening this afternoon, after I changed mimedefang-filter. When the slaves started dying, I reverted my changes, and restarted, but the problem persisted. I've tried running with the stock suggested-minimum-filter-for-windows-clients filter, same problem. Usually, this means that there's still a change in the mimedefang-filter that was missing. The usual reason that I get this major hiccup is because of some syntactical error (missing semicolon, etc..) I've taken a known good mimedefang-filter from another machine and the same symptoms occur. I truss'd the process and it seemed to occur after the spamassassin rules were being looked at. I pared down the number of third-party lists I was using (most notably the blacklist-uri series), and now things seem to be better. Thanks, Graham ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Slaves dying shortly after startup
This started happening this afternoon, after I changed mimedefang-filter. When the slaves started dying, I reverted my changes, and restarted, but the problem persisted. I've tried running with the stock suggested-minimum-filter-for-windows-clients filter, same problem. The multiplexor will start the two slaves, which will then use all the CPU available like so: CPU states: 95.0% user, 0.0% nice, 3.1% system, 1.9% interrupt, 0.0% idle Mem: 78M Active, 59M Inact, 30M Wired, 376K Cache, 48M Buf, 205M Free Swap: 512M Total, 512M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 9910 mailnull 53 0 26120K 25768K RUN 0:06 52.12% 22.07% perl 9921 mailnull 53 0 15476K 15096K RUN 0:04 48.24% 15.92% perl They'll run like that for a minute, then get die: Mar 28 23:00:46 media mimedefang-multiplexor: started; minSlaves=2, maxSlaves=10, maxRequests=500, maxIdleTime=300, busyTimeout=600, clientTimeout=10 Mar 28 23:00:46 media mimedefang-multiplexor: Starting slave 0 (pid 9910) (1 running): Bringing slaves up to minSlaves (2) Mar 28 23:00:47 media mimedefang[9920]: Multiplexor alive - entering main loop Mar 28 23:00:49 media mimedefang-multiplexor: Starting slave 1 (pid 9921) (2 running): Bringing slaves up to minSlaves (2) Mar 28 23:01:06 media mimedefang-multiplexor: Slave 0 stderr: Out of memory! Mar 28 23:01:06 media mimedefang-multiplexor: Reap: Idle slave 0 (pid 9910) exited normally with status 1 (SLAVE DIED UNEXPECTEDLY) Mar 28 23:01:06 media mimedefang-multiplexor: Slave 0 resource usage: req=0, scans=0, user=10.142, sys=0.557, nswap=0, majflt=0, minflt=14691, maxrss=31840, bi=0, bo=0 Mar 28 23:01:08 media mimedefang-multiplexor: Slave 1 stderr: Out of memory! Mar 28 23:01:08 media mimedefang-multiplexor: Reap: Idle slave 1 (pid 9921) exited normally with status 1 (SLAVE DIED UNEXPECTEDLY) Mar 28 23:01:08 media mimedefang-multiplexor: Slave 1 resource usage: req=0, scans=0, user=10.155, sys=0.473, nswap=0, majflt=0, minflt=14691, maxrss=31840, bi=0, bo=0 The multiplexor will then restart them and the cycle will continue indefintely. There's no mail coming into the system, nothing queued (mailq reports empty). Is there a way to see what they're trying to do? This is using perl from ports, and as far as I can see, the right version is getting hit: media# ls -l `which perl` lrwxr-xr-x 1 root wheel 19 Feb 24 15:32 /usr/bin/perl - /usr/local/bin/perl media# /usr/local/bin/perl -v This is perl, v5.6.1 built for i386-freebsd This is under freebsd 4.7, perl 5.6.1, mimedefang 2.41: Archive::Zip : yes HTML::Parser : yes HTML::TokeParser : yes Path:CONFDIR : yes (/usr/local/etc/mimedefang) Path:QUARANTINEDIR: yes (/var/spool/MD-Quarantine) Path:SENDMAIL : yes (/usr/sbin/sendmail) Path:SPOOLDIR : yes (/var/spool/MIMEDefang) SpamAssassin : yes Virus:CLAMAV : yes (/usr/local/bin/clamscan) Virus:CLAMD : yes (/usr/local/sbin/clamd) File::Scan: no HTMLCleaner : no Unix::Syslog : no Virus:AVP : no Virus:AVP5: no Virus:BDC : no Virus:FPROT : no Virus:FPROTD : no Virus:FSAV: no Virus:FileScan: no Virus:HBEDV : no Virus:NAI : no Virus:NVCC: no Virus:OpenAV : no Virus:SOPHIE : no Virus:SOPHOS : no Virus:SymantecCSS : no Virus:TREND : no Virus:TROPHIE : no Virus:VEXIRA : no Anomy::HTMLCleaner: missing Archive::Zip : Version 1.10 Digest::SHA1 : Version 2.07 File::Scan: missing HTML::Parser : Version 3.35 HTML::TokeParser : Version 2.28 IO::Socket: Version 1.26 IO::Stringy : Version 2.108 MIME::Base64 : Version 3.00 MIME::Tools : Version 5.411 MIME::Words : Version 5.404 Mail::Mailer : Version 1.60 Mail::SpamAssassin: Version 2.63 Unix::Syslog : Version 0.100 Thanks, Graham ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Increase Log Verbosity (was [Mimedefang] Slaves Dying Prematurely)
On Sun, 29 Feb 2004 20:17:13 -0500 David F. Skoll [EMAIL PROTECTED] wrote: On Mon, 1 Mar 2004, Peter A. Cole wrote: Mar 1 09:02:15 jake mimedefang-multiplexor: Reap: Idle slave 1 (pid 990) exited due to signal 11 (SLAVE DIED UNEXPECTEDLY) Signal 11 is a segmentation fault. There's something seriously wrong with your Perl installation; maybe a bad library or some other bad dependency? -- David. Hi again, still trying to track the source of this problem down. I can't really file a bug report on it until I know what part of mimedefang and associated modules and libraries is actually causing the problem. Can anyone suggest a way of increasing the verbosity of the log files at all? I need to find out at which stage of the filter it seg faults. Any tips will be greatly appreciated, and will hopefully lead to a successfully resolved bug! Thanks, Pete ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: Increase Log Verbosity (was [Mimedefang] Slaves Dying Prematurely)
On Mon, 1 Mar 2004, Peter A. Cole wrote: Can anyone suggest a way of increasing the verbosity of the log files at all? That is unlikely to help. I need to find out at which stage of the filter it seg faults. That is unlikely to help. A segfault is deep in the C guts of Perl; unless you're an experienced Perl hacker (by which I mean, experienced at hacking the C innards of Perl), knowing where it segfaults won't help much. If you can somehow force the generation of a core file, that might help someone who knows Perl well find the problem. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves Dying Prematurely
When I ran into this problem..I used the -l option when starting the mimedefang-multiplexor and it gave me a more detailed perl error message that allowed me to find the offending problem. You can also test the mimedefang-filter rules by hand like this: /dir_path_to_mimedefang_bin/mimedefang.pl -f /dir_path_to_mimedefang_filter/mimedefang-filter -test but know that will not get the errors you may be seeing sometimes, it just checks the syntax of teh filter so as to eliminate that problem. Note my problem when the slave died prematurely was not becuase of an upgrade of perl or modules but rather a call to a function that I had removed and this passed the syntax checker! Hope this helps. --Don --- [EMAIL PROTECTED] wrote: Date: Mon, 1 Mar 2004 10:10:36 +1000 From: Peter A. Cole [EMAIL PROTECTED] Subject: [Mimedefang] Slaves Dying Prematurely __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves Dying Prematurely
On Mon, 01 Mar 2004 12:56:05 -0700 Stephen Smoogen [EMAIL PROTECTED] wrote: Here is a web page that has a lot of info on Sig11. While it says its about compiling the Linux kernel.. I have found that it is pretty meaningful for most sig 11 issues http://www.bitwizard.nl/sig11/ Thanks for the link Stephen. I'm supposed to be packing up to head down the coast for a few days this morning, so I'll have a read of this when I get back, could be very useful for future reference. Pete ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: Increase Log Verbosity (was [Mimedefang] Slaves Dying Prematurely)
On Mon, 01 Mar 2004 08:07:11 -0500 David F. Skoll [EMAIL PROTECTED] wrote: That is unlikely to help. A segfault is deep in the C guts of Perl; unless you're an experienced Perl hacker (by which I mean, experienced at hacking the C innards of Perl), knowing where it segfaults won't help much. If you can somehow force the generation of a core file, that might help someone who knows Perl well find the problem. Regards, David. Thanks David, at least I know next time not to chase my tail as I wouldn't have a clue about C or Perl to sort that out. However, hopefully you've seen my response in another message in this thread that by enabling all logging I could find for the multiplexor, then recompiling sendmail.cf, it miraculously came back to life. So, although it's now working, I have no idea why it wasn't. Pete ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves Dying Prematurely
On Mon, 01 Mar 2004 10:19:18 -0800 Don [EMAIL PROTECTED] wrote: When I ran into this problem..I used the -l option when starting the mimedefang-multiplexor and it gave me a more detailed perl error message that allowed me to find the offending problem. You can also test the mimedefang-filter rules by hand like this: /dir_path_to_mimedefang_bin/mimedefang.pl -f /dir_path_to_mimedefang_filter/mimedefang-filter -test but know that will not get the errors you may be seeing sometimes, it just checks the syntax of teh filter so as to eliminate that problem. Note my problem when the slave died prematurely was not becuase of an upgrade of perl or modules but rather a call to a function that I had removed and this passed the syntax checker! Hope this helps. --Don Thanks Don, I think it did, sort of... I just went through my mimedefang.conf file and enabled everything to do with logging for the multiplexor, including stats etc. I then created the /var/log/mimedefang directory for the stats, changed owner to defang, and put mimedefang back into sendmail so I could test it. It has since delivered 3 messages with no problems. So, it's fixed, but I have no idea why as I did change any filter settings or anything, just log settings. Bizarre. I wonder if maybe the last time I ran sendmailconfig it stuffed part of the .cf file up or something? Pete ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves Dying Prematurely
On Mon, 1 Mar 2004, Peter A. Cole wrote: Mar 1 09:02:15 jake mimedefang-multiplexor: Reap: Idle slave 1 (pid 990) exited due to signal 11 (SLAVE DIED UNEXPECTEDLY) Signal 11 is a segmentation fault. There's something seriously wrong with your Perl installation; maybe a bad library or some other bad dependency? -- David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves Dying Prematurely
On Sun, 29 Feb 2004 20:17:13 -0500 David F. Skoll [EMAIL PROTECTED] wrote: On Mon, 1 Mar 2004, Peter A. Cole wrote: Mar 1 09:02:15 jake mimedefang-multiplexor: Reap: Idle slave 1 (pid 990) exited due to signal 11 (SLAVE DIED UNEXPECTEDLY) Signal 11 is a segmentation fault. There's something seriously wrong with your Perl installation; maybe a bad library or some other bad dependency? -- David. Thanks David, I was trying to find out what that Signal 11 meant, but couldn't seem to find any reference to it. In that case, I would expect that maybe the current Perl package has some issues. I'll check on the bugs etc. for Debian. Thanks for the tip! Pete ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Slaves Dying Prematurely
On Sun, 29 Feb 2004 20:17:13 -0500 David F. Skoll [EMAIL PROTECTED] wrote: On Mon, 1 Mar 2004, Peter A. Cole wrote: Mar 1 09:02:15 jake mimedefang-multiplexor: Reap: Idle slave 1 (pid 990) exited due to signal 11 (SLAVE DIED UNEXPECTEDLY) Signal 11 is a segmentation fault. There's something seriously wrong with your Perl installation; maybe a bad library or some other bad dependency? -- David. One thing I forgot to ask. Is there a way someone who knows absolutely nothing about Perl can determine what is actually causing the segfault? I want to try to pinpoint it to Perl itself or a module or library etc. so I can check the buglist out for this. There's quite a few bugs listed for Perl, some of which relate to segfaults, but none that I can see easily that relate to mimedefang. Thanks again, Pete ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
