Charlie Brady escribió:
This is where I pop up and remind folks there's a long-standing bug that
no time limits are applied to plug-in callbacks.
Right now I don't know if plugin callbacks would solve this problem. I'm
starting to think it is DESTROY related... I feel that plugin timeouts
are a more profund discussion, so I won't get into it (yet).
I've been bugging aroung the Qp code to find what's going on with these
processes... What was my surprise when I saw:
$SIG{ALRM} = sub {
print $client "421 Connection Timed Out\n";
::log(LOGINFO, "Connection Timed Out");
exit; };
in the qpsmtpd-forkserver code... just in the portion of code for child
processes :)
The bad thing is that it is never called, because alarm is never called
:S ¿Is there any other way to send yourself ALRMs?
When you send an ALRM to one of the hung processes, it exits... It looks
like this feature got in to forkserver at rev 291... but it seems like
it never worked... Maybe a plugin was supposed to call alarm? Maybe the
parent process was supposed to send the ALRM to a child that has been
working for too long? (that way you don't have to worry about plugins
that touch the ALRM handler... I'm not saying the plugin developer does
it consciouslly... maybe just the classes he uses...).
Is it safe to just make a plugin that hooks to the connect and does an
alarm($session_timeout). It will only be usable for the forkserver, but
at least it's something.
I also saw that in SMTP.pm there are two commented out lines referring
to ALRMs... so it looks like the session timeout was a working feature
at some point...
What do you guys think about restoring this feature?
Jose Luis Martinez
CAPSiDE
[EMAIL PROTECTED]
