On 16-6-2011 16:12, David F. Skoll wrote:
We already poll for that one; see the mimedefang.c source file. In fact, the reason the milter socket takes so long to appear is that currently, it doesn't get created until *after* the multiplexor is up and running.
Oh I realize that we are already polling for the socket to become available 50 times waiting for 3 sec between polls. This is good as the socket does probably come late. What I wanted to ask if it's important that we actually have this socket after waiting for 2.5 min.
MXCheckFreeSlaves(MultiplexorSocketName) sets mx_alive to 1 if the socket is available or if all polls were exhaused mx_alive stays 0. The only difference is the log message that is generated. Even if for some strange reason the socket is not available after the polling loop we dive into smfi_main anyway logging the message "Multiplexor unresponsive - entering main loop anyway".
I was wondering if that's bad :), ie what would happen if for instance the socket was not available and we dove into smfi_main anyway. Does code try to reconnect or does it never attempt this. If we don't reconnect, and thus will never recover, in my opinion we should do something more drastic than log one message mentioning this.
True waiting 2.5 min seems more than enough for next to all situations was just referring to the edge cases.
Regards -- Michiel Brandenburg _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
