Re: Relating to Domains..

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Wed, 28 Sep 2011 22:30:26 -0700 (PDT)

[re-sending to the list]

On Wed, 28 Sep 2011, N. wrote:
> [root_at_private ~]# cat strace.out
> 26712 rt_sigtimedwait([HUP INT TERM], <unfinished ...>
> 26711 rt_sigtimedwait([USR1], <unfinished ...>
> 26710 select(4, [3], NULL, [3], {1, 441000}) = 0 (Timeout)
> 26710 select(4, [3], NULL, [3], {5, 0}) = 0 (Timeout)
> 26710 select(4, [3], NULL, [3], {5, 0}) = 0 (Timeout)
> 26710 select(4, [3], NULL, [3], {5, 0}) = 0 (Timeout)
> 26710 select(4, [3], NULL, [3], {5, 0}) = 0 (Timeout)
> 26710 select(4, [3], NULL, [3], {5, 0}) = 0 (Timeout)

Looks to me like postfix never made contact with opendkim. You would see
a call to select() complete rather that timeout, and there would then be a
call to accept() followed by a series of read()/recvfrom() and
write()/sendto() calls as they communicate.

Is it possible you have a packet filter interfering with socket
communication? You should see some timeouts or other errors from the
postfix side in that case as it tries but fails to reach the filter, or
you might see activity in the packet filter's logs that show it's
blocking the I/O from postfix.

You might try using a UNIX domain socket rather than a TCP socket if
that's the case, as these tend to bypass packet filters, such as this in
opendkim.conf:

          Socket local:/var/run/opendkim/opendkim.sock

...and similar configuration on the postfix side. Just make sure the
postfix process has permission to access the socket.

-MSK
Received on Thu Sep 29 2011 - 05:30:43 PST