Mailing List Archive

"nclamd" - An alternative "clamd"
Some time ago I made some postings about the problems I was getting with
"clamd", particularly very large memory leaks, and I suggested a different
architecture that I thought would be more appropriate. Particularly I don't like
the concept of using threads for a network daemon, because all leaks are
automatically inherited by all threads.

I was also unhappy with the MIME decoding and having tested "ripmime" found it
to be faster and pretty much leak proof.

However, Clam was doing a fine job in the actual scanning and identification of
viruses and keeping the database up-to-date. So I wanted to re-write "clamd",
"clamav-milter" and "clamdscan" to use "libripmime" and "libclamav". This I did
and called it "nclamd" (New-clamd) and was first published in late September
this year.


It uses a similar architecture to Apache. It has a control process that monitors
the service socket and looks for database updates (but doesn't do any actual
scanning) and it has a number of child processes that actually scan.

When a connection comes in, the first child to pick up the connection gets it,
reads a command (followed by an LF). It then goes in to one of a number of modes
according to the command read. These are Scan a file by name, scan a file
stream, scan an e-mail by file name, scan an e-mail stream. You can also force a
child to died and force the master control to re-load the database.


The number of child processes running at any one time depends on the number of
connections queuing on the service socket. If there are outstanding connections
in the queue, the Master controller will spawn new child processes up to a
pre-defined upper limit. If a child is idle for more than a pre-defined time, it
will die. The Master Controller will always ensure that a pre-defined number of
child processes are always alive.

When the Control process detects the database has been updated, it will load the
new database and then kill the child processes, one at a time with a delay
between each kill to ensure it doesn't cause loss of service, or cause the
system to thrash.

A child will only service a pre-defined number of requests before it will
spontaneously die. This will ensure that any memory leaks will be cleaned up
after a period of time, whether there system is relatively busy or relatively idle.

All these pre-defined limits can be changed on the "nclamd" command line.


I first published this new code towards the end of September. We have now
installed it on about 30 systems at small and medium sized businesses in our
area and it is proving very solid. Although, we have run into a timeout issue in
the sendmail milter interface that is explained in a README.

The code is available at http://www.kyzo.com/nclamd/ - its GPL, so do what you
like with it. I have compiled it on Slackware v7.0 and Slackware v8.1 for other
platforms it may require minor changes.



James
Re: "nclamd" - An alternative "clamd" [ In reply to ]
On Mon, 03 Nov 2003 10:26:35 +0000
James Stevens <James@kyzo.com> wrote:

> Some time ago I made some postings about the problems I was getting
> with "clamd", particularly very large memory leaks, and I suggested a

Most memory leaks have been fixed and now the only problematic code is
that of unrarlib (huge leaks) and mail decoder (sometimes crashes but
it's far more stable now).

> I first published this new code towards the end of September. We have
> now installed it on about 30 systems at small and medium sized
> businesses in our area and it is proving very solid. Although, we have
> run into a timeout issue in the sendmail milter interface that is
> explained in a README.

nclamd will be described in a documention of next stable release (it
should be available on Friday). This is still a very new software and we
must test it. Sorry - I had no time to check the sources but will do it
when the new version is released.

Best regards,
Tomasz Kojm
--
oo ..... http://www.clamav.net/gpg/tkojm.gpg
(\/)\......... 0DCA5A08407D5288279DB43454822DC8985A444B
\..........._ Mon Nov 3 15:30:55 CET 2003
//\ /\