It can also be a bug in the kernel according to this post:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1390223
It's the same kind of behaviour and Ubuntu utopic (and event postfix)
is mentioned. I'm running the same version of kernel on the host
server which is mentioned in the text.
One post in the link above claims that the bug has been fixed in
kernel 3.18.0-8.9.
However this is clearly not a postfix issue. I want to thank for the
suggestions and explanations from Wietse V and Viktor D that lead to
the right track to solve this.
/Regards Mats
Quoting Viktor Dukhovni <postfix-us...@dukhovni.org>:
On Sat, Feb 14, 2015 at 11:43:43PM +0100, Mats Luspa wrote:
Thanks for your suggestion. It seems to be some Permission denies in the
trace-file that comes below:
socket(PF_LOCAL, SOCK_STREAM, 0) = 16
fcntl(16, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(16, F_SETFL, O_RDWR) = 0
connect(16, {sa_family=AF_LOCAL, sun_path="private/bounce"}, 110) = 0
poll([{fd=16, events=POLLOUT}], 1, 3600000) = 1 ([{fd=16, revents=POLLOUT}])
write(16, "nrequest\0000\0flags\0000\0queue_id\00067C9"..., 469) = 469
poll([{fd=16, events=POLLIN}], 1, 3600000) = 1 ([{fd=16,
revents=POLLIN|POLLHUP}])
read(16, 0x7f4e5a2cc180, 4096) = -1 EACCES (Permission denied)
close(16) = 0
Interesting that connect(2) and write(2) succeed, but then poll(2)
for read returns POLLHUP, and read returns EPERM. Sure seems like
some sort of misconfigured security policy allowing writes but not
reads. Race conditions and the like seem unlikely at first blush.
--
Viktor.
