Bug #50912 for File-Scan-ClamAV: ClamD ping() blocking

Wed Oct 28 07:24:51 2009 grayhat [...] gmx.net - Ticket created

Subject:	ClamD ping() blocking
Date:	Wed, 28 Oct 2009 12:23:53 +0100
To:	<bug-File-Scan-ClamAV [...] rt.cpan.org>
From:	"GrayHat" <grayhat [...] gmx.net>

Hello! What I'm submitting here is a "feature request" more than a bug, or, at least it isn't directly a bug lying inside the perl module in question (File::Scan::ClamAV); I'll try to describe the issue the better I can Imagine having a ClamD daemon taking some time while reloading signatures (e.g. due to 3rd party signatures or the like); an example being the following one Wed Oct 28 10:23:27 2009 -> Reading databases from C:\ASSP\clamAV\data Wed Oct 28 10:24:26 2009 -> Database correctly reloaded (896020 signatures) now; if during the reload process (but the same applies to other "blocking" operations like generating statistics and so on) I was saying... if during the reload process you try to issue (e.g.) an clamdscan something you'll see that the scanner will "hold" and won't start working until the reload process won't complete; this is due to the fact that while the ClamD is running some "blocking" operations it will still accept connections but whatever command will be sent to the daemon will be just queued and kept "on hold", then, once the "blocking operation" completes, ClamD will start dequeueing and processing the pending commands The above causes some undesired side effects; imagine having an application which uses ClamD (through File::Scan::ClamAV) to scan incoming SMTP traffic (emails); now, in case ClamD will go "on hold" as seen before, the app will get "stuck" and lock until the scanner won't be available again Using the "ping()" method in this case won't solve the issue since the ping will successfully connect (as I wrote ClamD will accept connections) but then will wait "forever" to get an answer to the "PING" string he sent What I'm asking is to add a "timeout" to the "ping()" method (optionally to the scan ones) so that, in case ClamD "goes on hold" the client won't get "stuck", in such cases the call to "ping()" or "scan()" will just return a timeout error and the app may then deal with it as needed; I know it's only a "workaround" and a better solution would be changing the ClamD behaviour, but since fixing or changing the ClamD code would imHo take much more than just adding a timeout inside the File::Scan::ClamAV module I'm here begging for such an option All the best

Tue Apr 28 07:41:17 2015 ESAYM [...] cpan.org - Correspondence added

On Wed Oct 28 07:24:51 2009, grayhat@gmx.net wrote: Show quoted text

> > Hello! > > What I'm submitting here is a "feature request" more than > a bug, or, at least it isn't directly a bug lying inside the perl > module in question (File::Scan::ClamAV); I'll try to describe > the issue the better I can > > Imagine having a ClamD daemon taking some time while > reloading signatures (e.g. due to 3rd party signatures or > the like); an example being the following one > > Wed Oct 28 10:23:27 2009 -> Reading databases from C:\ASSP\clamAV\data > Wed Oct 28 10:24:26 2009 -> Database correctly reloaded (896020 > signatures) > > now; if during the reload process (but the same applies to other > "blocking" operations like generating statistics and so on) I was > saying... if during the reload process you try to issue (e.g.) an > > clamdscan something > > you'll see that the scanner will "hold" and won't start working > until the reload process won't complete; this is due to the fact > that while the ClamD is running some "blocking" operations it > will still accept connections but whatever command will be sent > to the daemon will be just queued and kept "on hold", then, > once the "blocking operation" completes, ClamD will start > dequeueing and processing the pending commands > > The above causes some undesired side effects; imagine having > an application which uses ClamD (through File::Scan::ClamAV) > to scan incoming SMTP traffic (emails); now, in case ClamD > will go "on hold" as seen before, the app will get "stuck" > and lock until the scanner won't be available again > > Using the "ping()" method in this case won't solve the issue > since the ping will successfully connect (as I wrote ClamD > will accept connections) but then will wait "forever" to get > an answer to the "PING" string he sent > > What I'm asking is to add a "timeout" to the "ping()" method > (optionally to the scan ones) so that, in case ClamD "goes > on hold" the client won't get "stuck", in such cases the call > to "ping()" or "scan()" will just return a timeout error and > the app may then deal with it as needed; I know it's only > a "workaround" and a better solution would be changing > the ClamD behaviour, but since fixing or changing the > ClamD code would imHo take much more than just > adding a timeout inside the File::Scan::ClamAV module > I'm here begging for such an option > > All the best >

This is a good idea. It should be easy enough to make ping() nonblocking by simply forking a process on the call to ping() and setting an alarm timeout or something similar. However, I am not sure how to add a timeout to the normal scan functions. For one reason, it would be difficult to determine the difference between clamd blocking and clamd simply taking a long time to scan a file. It could be done, but caution would be needed to ensure one doesn't timeout a scan that is just taking too long due to file size or something similar.

Tue Apr 28 07:41:18 2015 The RT System itself - Status changed from 'new' to 'open'

Tue Apr 28 07:42:50 2015 ESAYM [...] cpan.org - Severity Wishlist added