><RANT>I'm not sure I really understand why Tomasz / Nigel seem so reluctant to use ripmime / libripmime, when it seem to be to be a better solution, and will soon have OLE unpacking support</RANT>
If I remember correctly, the license of libripmime doesn't allow us to use it in libclamav.
You are kind of right, in that the "LICENSE.TXT" is unclear and the web sites says BSD license, so I mailed Paul to clarify this, he said :-
"ripMIME is BSD licensed, so, nothing stopping them using it"
> Change to 20030831 snapshot brought about stability, so fix no > longer needed in my case.
I'll give it a try, but seeing as 20030829 still leaked like hell (over 12Mb on 375 messages) and SEGV'ed on exactly the same e-mails that it had before (the two I had already sent to Nigel), I was kind of loosing faith. On some days the leaking alone was enough to crash the whole system - something had to be done.
My personal preference would be for a different structure to "clamd" so that SEGVs and leaks can't bring the service down.
Something like :-
load_database();
open_main_socket();
while(!SIGTERM)
{
alarm(60);
check_database();
select(sock,timeout);
if (FDSET(sock)
{
client = accept(sock)
if (!fork())
{
libripmime(tmpdir,client);
libclamscan(tmpdir);
}
}
}Forking for each incomming connection could work out expensive, but its essentially what clamd does already, but clamd forks a thread instead of a process - in Linux the two are very similar.
With this kind of structure ripmime and clamscan can crash and leak to their hearts content and the service will stay up.
A more sophisticated variation would be to load the database, open the main socket, then fork (say) 5 child process all running a blocking "accept", one of the child processes (whoever happens to have CPU at the time) will then be given the incomming connection and scan the data.
The child could then either die (and be re-started by the master) or go into another blocking "accept". You could then allow the child to scan, say 10 jobs, before it dies (and is re-started by the master). This is basically how Apache works.
Apache is slight more sophisticated still, in that the Apache master process also monitors the main request socket and if the queue is filling up it starts more child processes (to a MAX limit). As a further check, if a child hasn't answered a query after more than a certain period of time it is killed (by an SIGALRM) and the master re-starts it.
The master should also have a SIGALRM back stop, so that if it locks up, it dies. The master would then be run through inittab so that it is always immediately re-started.
This would give a really bullet proof scanning service and allow for a reasonable level of leaking / bugs in the scanning process itself.
I'd be more than happy to write and donate the code (I have most of it already), but you'd have to wait a week or two as I'm a bit busy on client work right now.
> It did not appear to pick up SoBig.
Its picked up over 4000 SoBig sent to me so far. You may need the "--mailbox" and the STDIN patch to ripmime (as per my previous posting).
Like I said before, we mainly use clam to scan mail one at a time using the milter, so not having the "--mailbox" option worked fine for me, up to a point.
James
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Clamav-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-devel
