[Clamav-users] Re: first impressions on 0.90
On 14/02/2007 20:09, Rick Pim wrote: it's true; if i start clamd and then check, the clamd socket isn't there. but if i leave clamd alone for a few seconds the socket appears and clamav-milter starts happily after that. i've tucked a sleep 30 into the startup script and things seem happy. is there anything obvious i'm missing? That will be because it forks before reading the database (which causes the delay) and before creating the sockets. I.e. the initial process exits before everything is ready. Maybe it would be better if it forked after creating the sockets. -- -=( Ian Abbott @ MEV Ltd.E-mail: [EMAIL PROTECTED])=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: first impressions on 0.90
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Abbott wrote: On 14/02/2007 20:09, Rick Pim wrote: it's true; if i start clamd and then check, the clamd socket isn't there. but if i leave clamd alone for a few seconds the socket appears and clamav-milter starts happily after that. i've tucked a sleep 30 into the startup script and things seem happy. is there anything obvious i'm missing? That will be because it forks before reading the database (which causes the delay) and before creating the sockets. I.e. the initial process exits before everything is ready. Maybe it would be better if it forked after creating the sockets. No, because then you would have two active sockets and a replicated database per instance (fork). Not good practice, unless you really want the results. - -James -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF1bbskNLDmnu1kSkRArsQAJ44sgqychWJuRugHRmCeYhXlwQduwCfUP1t O/Z39tvyKOIyRS4syKusj9c= =OhqU -END PGP SIGNATURE- -- Scanned by ClamAV - http://www.clamav.net ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: first impressions on 0.90
On 16/02/2007 13:51, James Kosin wrote: Ian Abbott wrote: On 14/02/2007 20:09, Rick Pim wrote: it's true; if i start clamd and then check, the clamd socket isn't there. but if i leave clamd alone for a few seconds the socket appears and clamav-milter starts happily after that. i've tucked a sleep 30 into the startup script and things seem happy. is there anything obvious i'm missing? That will be because it forks before reading the database (which causes the delay) and before creating the sockets. I.e. the initial process exits before everything is ready. Maybe it would be better if it forked after creating the sockets. No, because then you would have two active sockets and a replicated database per instance (fork). Not good practice, unless you really want the results. I can't think of any bad results in this case. The initial (parent) process just calls exit() straight after the fork() (a standard daemonization technique), closing all the duplicated file handles. Although the sum of the process images is larger if the fork is performed after loading the database, it's not that expensive assuming fork() uses a copy-on-write paging mechanism; it just uses more page table entries for an instant. -- -=( Ian Abbott @ MEV Ltd.E-mail: [EMAIL PROTECTED])=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: first impressions on 0.90
On Fri, Feb 16, 2007 at 03:04:42PM +, Ian Abbott said: On 16/02/2007 13:51, James Kosin wrote: Ian Abbott wrote: On 14/02/2007 20:09, Rick Pim wrote: it's true; if i start clamd and then check, the clamd socket isn't there. but if i leave clamd alone for a few seconds the socket appears and clamav-milter starts happily after that. i've tucked a sleep 30 into the startup script and things seem happy. is there anything obvious i'm missing? That will be because it forks before reading the database (which causes the delay) and before creating the sockets. I.e. the initial process exits before everything is ready. Maybe it would be better if it forked after creating the sockets. No, because then you would have two active sockets and a replicated database per instance (fork). Not good practice, unless you really want the results. I can't think of any bad results in this case. The initial (parent) process just calls exit() straight after the fork() (a standard daemonization technique), closing all the duplicated file handles. Although the sum of the process images is larger if the fork is performed after loading the database, it's not that expensive assuming fork() uses a copy-on-write paging mechanism; it just uses more page table entries for an instant. What would be the point of having a socket ready before clamd is ready to do any work? Maybe I'm missing something. -- -- | Stephen Gran | You are only young once, but you can| | [EMAIL PROTECTED] | stay immature indefinitely. | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: first impressions on 0.90
On Fri, 16 Feb 2007, Stephen Gran wrote: What would be the point of having a socket ready before clamd is ready to do any work? Maybe I'm missing something. It would be something for other programs to connect to and wait for a response, instead of generating a socket does not exist error. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 948-3162 WestNet Internet Services of Westchester http://www.westnet.com/ ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: first impressions on 0.90
On 16/02/2007 15:14, Stephen Gran wrote: On Fri, Feb 16, 2007 at 03:04:42PM +, Ian Abbott said: On 16/02/2007 13:51, James Kosin wrote: Ian Abbott wrote: On 14/02/2007 20:09, Rick Pim wrote: it's true; if i start clamd and then check, the clamd socket isn't there. but if i leave clamd alone for a few seconds the socket appears and clamav-milter starts happily after that. i've tucked a sleep 30 into the startup script and things seem happy. is there anything obvious i'm missing? That will be because it forks before reading the database (which causes the delay) and before creating the sockets. I.e. the initial process exits before everything is ready. Maybe it would be better if it forked after creating the sockets. No, because then you would have two active sockets and a replicated database per instance (fork). Not good practice, unless you really want the results. I can't think of any bad results in this case. The initial (parent) process just calls exit() straight after the fork() (a standard daemonization technique), closing all the duplicated file handles. Although the sum of the process images is larger if the fork is performed after loading the database, it's not that expensive assuming fork() uses a copy-on-write paging mechanism; it just uses more page table entries for an instant. What would be the point of having a socket ready before clamd is ready to do any work? Maybe I'm missing something. My proposal is to change the order from: * fork (daemonize) * load database * open sockets to: * load database * open sockets * fork (daemonize) So the socket still won't be ready until clamd is ready. The point is to stop the initial process from exiting until everything is set up, so that a script can run clamd (in daemonizing mode) and know that everything is set up as soon as the command returns, rather than having to sleep for some arbitrary and ill-defined amount of time afterwards. -- -=( Ian Abbott @ MEV Ltd.E-mail: [EMAIL PROTECTED])=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: first impressions on 0.90
On Fri, Feb 16, 2007 at 03:28:18PM +, Ian Abbott said: On 16/02/2007 15:14, Stephen Gran wrote: What would be the point of having a socket ready before clamd is ready to do any work? Maybe I'm missing something. My proposal is to change the order from: * fork (daemonize) * load database * open sockets to: * load database * open sockets * fork (daemonize) So the socket still won't be ready until clamd is ready. The point is to stop the initial process from exiting until everything is set up, so that a script can run clamd (in daemonizing mode) and know that everything is set up as soon as the command returns, rather than having to sleep for some arbitrary and ill-defined amount of time afterwards. Ah, that makes some sense. What I did in another application that needed this sort of thing was to have this sequence: parent: fork parent: sleep child: do setup (load databases here) child: open sockets child: signal parent that it was ready (sigusr1) parent: exit when signal received That way the parent sits foregrounded until the child is actually ready to do some work, and start up scripts take as long as that takes, so there's no race condition with sleeps. -- -- | Stephen Gran | Better late than never. -- Titus | | [EMAIL PROTECTED] | Livius (Livy) | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: first impressions on 0.90
On Fri, Feb 16, 2007 at 10:17:18AM -0500, Christopher X. Candreva said: On Fri, 16 Feb 2007, Stephen Gran wrote: What would be the point of having a socket ready before clamd is ready to do any work? Maybe I'm missing something. It would be something for other programs to connect to and wait for a response, instead of generating a socket does not exist error. So that they could potentially wait around until their internal timeout, instead of immediately returning? That really doesn't seem all that much like a win to me. I'd rather that the calling application was allowed to make an immediate decision (defer this mail, etc) than get stuck waiting waiting on a reply for an indeterminate amount of time. I grant you, it doesn't take clam all that long to load it's databases, but this idea you're advocating doesn't seem like very good application design to me. -- -- | Stephen Gran | Join in the new game that's sweeping| | [EMAIL PROTECTED] | the country. It's called | | http://www.lobefin.net/~steve | Bureaucracy. Everybody stands in a| || circle. The first person to do | || anything loses. | -- signature.asc Description: Digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: first impressions on 0.90
On Fri, 16 Feb 2007, Stephen Gran wrote: It would be something for other programs to connect to and wait for a response, instead of generating a socket does not exist error. So that they could potentially wait around until their internal timeout, instead of immediately returning? That really doesn't seem all that much like a win to me. I'd rather that the calling application was allowed to make an immediate decision (defer this mail, etc) than get stuck waiting waiting on a reply for an indeterminate amount of time. How is this any different than any other time something connects to the socket and waits for a response, say when clamd is reloading it's database, or is under high load ? To me it's simply a consistant behavior. However I do think the other option of the parrent process not exiting until the socket is created is also a good idea, possibly better. Since this is the way clamav-milter works without the --external option it is also consistant. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 948-3162 WestNet Internet Services of Westchester http://www.westnet.com/ ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: first impressions on 0.90
On Fri, 16 Feb 2007 15:28:18 + Ian Abbott [EMAIL PROTECTED] wrote: My proposal is to change the order from: * fork (daemonize) * load database * open sockets to: * load database * open sockets * fork (daemonize) This won't work. In hardware accelerated mode cl_load() initializes NodalCore libs which create a thread pool. And forking threads would be a bad thing. -- oo. Tomasz Kojm [EMAIL PROTECTED] (\/)\. http://www.ClamAV.net/gpg/tkojm.gpg \..._ 0DCA5A08407D5288279DB43454822DC8985A444B //\ /\ Fri Feb 16 22:26:23 CET 2007 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
