https://bz.apache.org/bugzilla/show_bug.cgi?id=69857
--- Comment #4 from Sam Vaughan <[email protected]> --- Hi Giovanni, I won't pretend I wrote this - it's Claude's analysis of the bug because it's been a while since I posted the report and my memory is hazy! Thank you very much for looking at this. Kind regards, Sam I've attached a minimal httpd.conf that reproduces it (httpd-bug69857.conf, verified today on OpenBSD 7.8 with the apache-httpd-2.4.65p0 package). It turns out nothing in my configuration is special - no vhosts, mod_perl or SSL are involved, and the stock package httpd2.conf already has both configuration prerequisites: mpm_prefork is the MPM the sample config enables, and "Listen 80" is a wildcard listener. The reason a quick test doesn't show it is that the trigger is a traffic pattern, not the configuration. dummy_connection() in server/mpm_unix.c is only reached from ap_mpm_pod_signal(), which prefork's perform_idle_server_maintenance() calls when idle_count > MaxSpareServers. A freshly started server sits at StartServers children and never crosses that threshold, so dummy_connection() is never called no matter how long it runs or how many sequential requests you send. (Graceful restart/stop also can't produce the log flood: ap_mpm_pod_killpg() only makes dummy connections for SERVER_READY scoreboard slots and stops at the first failure, so it logs at most one line - in my tests it logged none.) Reproduction with the attached conf: # httpd2 -f /etc/apache2/httpd-bug69857.conf # for i in $(jot 10); do nc -w 12 127.0.0.1 8099 </dev/null & done The ten idle connections force prefork to fork extra children. About 13 seconds later, when nc times out and the connections close, the children go idle, idle_count exceeds MaxSpareServers, and the culling starts: [Mon Aug 03 14:13:37.326455 2026] [core:warn] [pid 13676] (22)Invalid argument: AH00056: connect to listener on [::]:8099 [Mon Aug 03 14:13:38.335989 2026] [core:warn] [pid 13676] (22)Invalid argument: AH00056: connect to listener on [::]:8099 [Mon Aug 03 14:13:39.346144 2026] [core:warn] [pid 13676] (22)Invalid argument: AH00056: connect to listener on [::]:8099 ... (In this minimal config the first listener is the IPv6 wildcard; on my production server, with "Listen 80" plus "Listen 8080", the chosen listener is 0.0.0.0:8080. connect() to either wildcard fails with EINVAL on OpenBSD.) Note that it logs one warning per second *indefinitely*, not one per culled child: the dummy connection is the only mechanism that wakes a child blocked in accept(), so no child ever reads the pipe-of-death byte, idle_count never drops, and the parent retries every second. Each real request wakes one child, which then sees the pod byte and exits - so on a live server the flood self-sustains between traffic bursts, which is where my ~1000 messages/day come from. The functional impact is that excess idle children are only reaped as fast as new requests arrive. Two data points supporting the diagnosis: changing the listeners to "Listen 127.0.0.1:<port>" on one of our servers stopped the messages completely (16,648 in the previous log period, zero since), and the same wildcard config was silent on OpenBSD <= 7.6 because the ports patch then rewrote the connect() address to loopback inside apr_socket_connect(). Joe's suggestion in comment 1 matches what the OpenBSD ports commit recommends: substitute the loopback address (127.0.0.1 / ::1, matching lp->bind_addr->family) at connect time inside dummy_connection() when bind_addr is the wildcard, without touching lp->bind_addr itself. I'm happy to test a patch on OpenBSD. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
