Hi all,
FYI for Debian sendmail users, the same thing needed to be done on a
system running "wheezy", e.g., add the following to
`/etc/init.d/mimedefang':
I have seen this problem too, I have looked at the code and it seems
that there is a delay between the creation of the socket (using
smfi_setconn mimedefang.c line 2442) and exit of the parent process
after daemonizing. Could it be that the smfi_setconn only indicates the
intent to create the socket and does not do the actual socket creation
itself ? Just theorizing here mind you.
I seem to remember reading somewhere when this function fails, the only
place you can check it is in the smfi_main function. Might be that this
is the actual place that this socket is created. If this is the case
it's created after the fork this might explain the delay, and thus
wheezy (my flavor) messes up with parallel booting assuming mimedefang
is ready while it's still starting. Sendmail (in my case) is then
started and can not connect to the socket.
# Start mimedefang
printf "%-59s" "Starting $prog: "
rm -f $SOCKET> /dev/null 2>&1
$PROGDIR/$prog -P $PID -R $LOOPBACK_RESERVED_CONNECTIONS \
<snip>
RETVAL=$?
if [ $RETVAL = 0 ] ; then
+ #
+ # To avoid a warning message when sendmail is started,
+ # give some time to create the Milter socket file.
+ #
+ sleep 2
Might be better to add some sleeping loop here checking on the
appearance of the socket, on some of my systems it appears in 1 sec
others 2-3 seconds. As a server might do all of it's init.d within 10
sec .. adding 2 sec sleeping time seems horrible :)
A better fix might be to let the parent process exit only when the
socket has been created, don't know if this is a wanted feature but it
might be the best solution. A non-zero exit status can be returned if
this socket does not appear in a certain time frame. If the choice is
made to change mimedefang.c it might also be best to move the waiting on
the multiplexor being alive (it's checked 50 times at 3 sec intervals
after the fork) so we can be sure all is ok before we tell the world all
is well when in fact something failed. Not sure a connection attempt is
made after entering smfi_main, but logging 'Multiplexor unresponsive -
entering main loop anyway' seems to indicated that that case might fall
into the bad category.
That or we can ask the libmilter ppl to keep trying to connect and not
assume that the socket will never appear, not sure how that will work
out though.
As an additional item for Debian mimedefang/sendmail users, you may
need to tweak the ownership of a couple of files:
I added smmsp to the defang group that seems to work too, no need to
change the init.d script in my case. Adding this user to the defang
group may introduct security issues as the mail server can then read /
write most of the internal mimedefang temp files, on the other hand the
mailserver supplied mimedefang with the data.
Adding the mailserver user to the defang group allows postfix / sendmail
configurations to use the same init.d script .. add postfix to defang
group or add smmsp :) Or run mimedefang as another user/group, my
thoughts are to keep this out of the init.d scripting as there probably
is no 100% correct way to do this for all platforms out there.
--
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
