https://bz.apache.org/bugzilla/show_bug.cgi?id=70265
Bug ID: 70265
Summary: test_proxy_beacon.py flaky: "added backend" logged
twice from two different child pids in one test
session
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Linux
Status: NEW
Severity: minor
Priority: P2
Component: Other Modules
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Observed on GitHub Actions CI (UBSan job, --enable-mods-shared=reallyall
--disable-http2) while running an unrelated PR (apache/httpd#838):
tests/t/modules/test_proxy_beacon.py::test_proxy_beacon failed:
AssertionError: backend should be added exactly once; saw 2:
['[Tue Oct 13 06:46:53.387756 2026] [proxy_beacon:notice] [pid 47898:tid 47900]
AH10579: mod_proxy_beacon: added backend http://localhost:8529 to
balancer://beacon',
'[Tue Oct 13 06:47:03.599798 2026] [proxy_beacon:notice] [pid 47919:tid 47921]
AH10579: mod_proxy_beacon: added backend http://localhost:8529 to
balancer://beacon']
Note the two different pids, ~10s apart, within the same nominal test session.
Likely mechanism: the test suite's "framework" fixture
(test/pytest_suite/conftest.py) starts httpd exactly once per pytest session
(HttpdServer.start(), scope="session") and never restarts it mid-session.
mod_watchdog runs its singleton callback in exactly one MPM-event child process
at a time, and mod_proxy_beacon's "already announced this backend" dedup state
(ctx->seen) lives in that child's own memory, not in shared memory. If MPM
event recycles/replaces the child currently holding the watchdog singleton
during the test's observation window, the newly-elected child starts with an
empty ctx->seen and legitimately logs "added backend" again when it next
receives the backend's announcement — which is correct per-process behavior,
but breaks the test's assumption that "added backend" is logged exactly once
per session.
This looks like the same class of fragility already partially addressed by
commit de77830152 ("Fix false negatives checking error_log with
test_proxy_beacon", PR #701), which introduced session_log_start specifically
because error_log state is not clean between pytest invocations — but that fix
did not account for the singleton owner itself migrating to a different child
mid-session.
I have not yet confirmed from the raw CI log whether the child was
crash-recycled or just cycled under normal MPM-event lifecycle/resource
pressure (a separate, likely-unrelated job in the same CI run hit AH03490
scoreboard-full around the same time, filed separately). Reporting this as a
CI-flake / possible test or mod_watchdog-singleton-ownership-handoff issue for
investigation; no code fix proposed yet.
CI run for reference: apache/httpd PR #838, UBSan job.
--
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]
