Since I needed to compile Postfix, I thought this could be the opportunity to
check the state of kqueue on Mac OS X at the same time: the most recent thread
I could find about those matters is the one that started with
http://www.mailinglistarchive.com/html/postfix-devel@postfix.org/2007-03/msg00051.html.
This is with Postfix 2.10.0 on Mac OS X 10.8.3.
The change introduced in the makedefs file is:
--- makedefs.original 2013-02-04 02:33:13.000000000 +0100
+++ makedefs 2013-03-21 13:47:26.000000000 +0100
@@ -476,7 +476,11 @@
*) CCARGS="$CCARGS
-DRESOLVE_H_NEEDS_ARPA_NAMESER_COMPAT_H";;
esac
# kqueue and/or poll are broken up to and including
MacOS X 10.5
- CCARGS="$CCARGS -DNO_KQUEUE"
+ #CCARGS="$CCARGS -DNO_KQUEUE"
+ case $RELEASE in
+ 12.*) ;;
+ *) CCARGS="$CCARGS -DNO_KQUEUE" ;;
+ esac
# # Darwin 8.11.1 has kqueue support, but let's play safe
# case $RELEASE in
# [1-8].*) CCARGS="$CCARGS -DNO_KQUEUE";;
Note that the change is a conservative one, since I haven't tried on Mac OS X
10.7 (Darwin 11) and earlier.
The change described in my other post ("Mac OS X and setrlimit(2)") is required
as well, since one will now call open_limit(INT_MAX) instead of
open_limit(FD_SETSIZE).
No compilation errors.
Not even a single additional warning. :-)
And the master process starts without a glitch.
So, let's consider the check-list from aforementioned message:
> Postfix 2.4 release candidate 8 attempts to use kqueue() and poll()
> on MacOS 10.4 and later. This should work but it would be nice if
> someone could confirm that:
>
> - the master starts smtpd processes as expected,
OK.
> and smtpd can receive mail as expected.
OK: tested with "telnet 127.0.0.1 25", and mail sent to <luttgens@[127.0.0.1]>
> - smtpd correctly times out when the client says nothing
> for a long time (just telnet to the SMTP port and wait).
OK: "timeout after CONNECT from localhost[127.0.0.1]" after exactly 5 minutes.
> - "postfix reload" starts a new queue manager immediately.
OK.
> An smtp-source/sink test can help to further confirm proper operation
> but should not be necessary.
OK: performed exactly the same test as the one described by Victor in
http://www.mailinglistarchive.com/html/postfix-devel@postfix.org/2007-03/msg00052.html.
So, looks quite promising. :-)
Are there other tests I could/should run in order to be fully reassured?
Axel
