https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6953
--- Comment #5 from Mark Martinec <[email protected]> --- > > See also Bug 7106. (not exactly a duplicate, but closely related) > I think the change in Bug 7106 also provides a workaround for the > case described in this bug. Needs to be tested... Now with less stringent checks put in place by Bug 7106#c4, we can afford to swap the order of bindings in pairs 0.0.0.0 with ::, and 127.0.0.1 with ::1 . Previously we tried binding to an IPv4 socket first, followed by an IPv6, with the following small change we do the reverse: Bug 6953: spamd: could not create IO::Socket::INET6 socket on [::]:783: Address already in use' spamd/spamd.raw Sending spamd/spamd.raw Committed revision 1655345. In many cases the order does not matter: - when one or the other protocol family is not supported in the kernel at all, or - when IO::Socket::IP version 0.09 or newer is installed, or - when IO::Socket::INET6 is not installed, or - when a binding address is explicitly provided by a spamd --listen (or -i) option, or - when option -4 or -6 is given to spamd, or - when sysctl setting net.ipv6.bindv6only (Linux) or net.inet6.ip6.v6only (BSD) is set to 1 (which is a default on FreeBSD, and configurable in any OS) It only matters if none of the above applies. In this case, prior to the Bug 7106#c4 change and the above swap we'd get a fatal error as is the topic of this problem report. Now spamd successfully binds to :: (i.e. an 'any' address') and because of the sysctl setting it is willing to accept also connections to this IPv6 socket over an IPv4 protocol family. When it tries next to bind to 0.0.0.0 (i.e. an IPv4-only 'any' address), this fails with: "Address already in use", but thanks to the change in Bug 7106 this is now only a warning issued on a spamd start, but later it works fine, accepting both protocol families over a single IPv6 socket. Perhaps the only detail to be considered is whether a warning issued during a spamd start would upset some startup script. If this is an issue, the warning could be downgraded to an info. The warning can also be avoided by any of the measures in the above list. -- You are receiving this mail because: You are the assignee for the bug.
