John:
what do you mean by "delete.net" domain ? you have a bogus virtualdomain to
catch spammers?
regards,
Ingo Claro
Gerente de Operaciones
[EMAIL PROTECTED]
(+56-2) 43 00 155
-----Mensaje original-----
De: John Simpson [mailto:[EMAIL PROTECTED]
Enviado el: Viernes, 28 de Octubre de 2005 3:09
Para: vchkpw@inter7.com
Asunto: Re: [vchkpw] How expensive is reloading the tcp.smtp.cdb?
On 2005-10-26, at 1805, ISP Lists wrote:
> Related to my earlier post, how expensive is it - resource-wise - to
> reload a tcp.smtp file of 100-1000 lines?
if it's anything like mine, with currently 56,270 lines and more added every
time some spammer sends a message to an email address in the "delete.net"
domain, it takes almost no time at all.
best of all, nothing has to be "restarted" afterward- while the processing
is happening, any tcpserver processes will continue to use the old file as
the new one is built... and when the processing is done, the new one is
renamed over the old one, so there is no danger of any tcpserver process
ever trying to use a "halfway done" file.
> If I have processing that is updating tcp.smtp every 5-10 minutes and
> I choose to reload the cdb from that tcp.smtp, is that a bad idea?
i do this every one minute- i have a cron job which generates the text file,
diffs it against the prior version, and rebuilds the cdb file only if the
text file has changed. the overall procedure has no noticeable impact on the
system- and the perl scripts which generate the text file eat ten times the
CPU and memory that the "tcprules"
command (which actually builds the cdb file) does.
> The "qmailctl cdb" command runs very fast for me now, but I don't have
> any idea what impact it has on any smtpd instances having to restart
> or re-read.
>
> Anyone know?
no impact at all. nothing ever has to restart or re-read.
qmail-smtpd doesn't know what a tcp.smtp file is, tcpserver does...
and tcpserver re-opens the file for every incoming connection, so whatever
the "current" file is at the time tcpserver calls open(), that's the file it
reads. if tcprules happens to do the rename while tcpserver has the file
open, it retains its existing handle on the old file (which now has no name
pointing to it) until it calls close
() after checking the remote IP address.
nice thing about renaming a file... it's atomic, meaning that it happens all
at once- there is no possible way for tcpserver to open the file "in the
middle of" the rename() call... either it happens before rename() or after
rename().
--------------------------------------------------
| John M. Simpson - KG4ZOW - Programmer At Large |
| http://www.jms1.net/ <[EMAIL PROTECTED]> |
--------------------------------------------------
| Mac OS X proves that it's easier to make UNIX |
| pretty than it is to make Windows secure. |
--------------------------------------------------
