On 16/02/2007 15:14, Stephen Gran wrote:
On Fri, Feb 16, 2007 at 03:04:42PM +0000, 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