cloud-hosting-platform/cloud-apache-container
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(lsphp): stop SIGPIPE+pipefail reporting the parity extension as missing

Browse Source 
`entrypoint-lsphp.sh` decided whether cac_path_parity was loaded with

    printf '%s\n' "$LSPHP_INFO" | grep -q '^cac_path_parity support => enabled$'

under `set -euo pipefail`. `grep -q` exits on its first match; printf is still
writing the remaining ~40 KB of `lsphp -i`, takes SIGPIPE, exits 141, and
pipefail prefers 141 over grep's 0. The branch therefore evaluated FALSE
*because the extension was present* — present early enough to stop the reader —
and every affected container fell back to the auto_prepend normaliser that a
customer's own .user.ini silently displaces, i.e. the exact failure the
extension exists to remove. Measured on whp02 against the published
cac-lsphp:php83: 5/5 runs status=141 with pipefail, 0 without.

The race is decided by pipe capacity, which is why it reproduced on whp02 and
not on other daemons: while the payload fits the pipe the writer never blocks
and always finishes first. Forced over the limit it is deterministic — 3x the
same `lsphp -i` (122100 bytes) gives 141 every time in the built image.

Fixed by reading with here-strings, which are not pipelines at all, so there is
no second exit status for pipefail to adopt. Same grep/awk patterns; plumbing
only. Same class fixed everywhere it existed under pipefail:

  * entrypoint-lsphp.sh      parity probe, and the SCAN_DIR awk probe
  * entrypoint-litespeed.sh  SCAN_DIR probe (a bare assignment: 141 there does
                             not degrade, `set -e` kills PID 1), and ols_running
  * entrypoint-shared-ols.sh ols_running
  * render-shared-ols-config.sh  site.meta parsing (`sed | head -1`): measured
                             141 at 6000 duplicate keys, which under `set -e`
                             aborts the whole render
  * fpm-parity-check.sh      the `php-fpm -m` pre-flight, whose whole job is to
                             stop a harness fault being blamed on the extension

Also: the fallback used to announce "cac_path_parity extension not loadable in
this image" for every reason the branch was reached, including its own plumbing
breaking — a false diagnosis that sends operators to rebuild a good image whose
build gate passed. Verdicts now carry the evidence they rest on, and a probe
that produced nothing is reported as a probe failure that establishes nothing
about the image. Fail-open posture is unchanged: no probe failure is fatal.

Adds scripts/tests/lsphp-info-probe.test.sh, which runs the shipped probes
(extracted verbatim, so they cannot drift from what runs in production) under
`set -euo pipefail` against a realistic ~40 KB phpinfo body, and statically
outlaws the shape repo-wide. Against trunk it fails, naming all 9 offending
lines. Wired into CI as a new Shell-Checks job, because no existing gate ever
executed the entrypoint's branch logic — the .phpt suite and the Dockerfile's
own `lsphp -i | grep -q` probe (which has no pipefail) were both green for the
release whose entrypoint declared that same extension missing.

Verified: PHP 8.3 --no-cache build green, 10/10 .phpt, 9/9 FPM harness; the
built image logs `path parity = extension` and reports `Rewriting => active`
with .from/.to populated; ext-removed and probe-broken variants each produce
their own honest message and still start.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
shadowdao
2026-08-05 15:23:56 -07:00
co-authored by Claude Opus 5
parent 9343a56ccf
commit 8790b027a9
7 changed files with 543 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scripts/entrypoint-lsphp.sh
+88 -4
View File
@@ -173,9 +173,68 @@ validate_ini_num() {
## `-i` ONLY: lsphp is the LSAPI SAPI, not the CLI — it accepts just
## -[b|c|n|h|i|q|s|v|?] and answers `-m`/`-r` by printing usage and exiting 0, so
## a `lsphp -m | grep` test never matches and never errors either.
##
## ---- CAC-TEST: probe helpers BEGIN ----
## Everything between these two markers is extracted verbatim and executed by
## scripts/tests/lsphp-info-probe.test.sh — the markers are inert comments with
## no runtime effect, and they exist so the test exercises THE SHIPPED CODE
## rather than a copy of it that can drift away from it.
##
## WHY THESE READ `$1` FROM A HERE-STRING AND NOT A PIPELINE. Both probes used
## to be `printf '%s\n' "$LSPHP_INFO" | <reader>`. `lsphp -i` is ~40 KB and both
## readers stop early — `grep -q` on first match, `awk` at `exit` — so the
## reader can close the pipe while printf is still writing to it. printf then
## takes SIGPIPE and dies 141, `set -o pipefail` (line 34) adopts 141 as the
## PIPELINE's status, and the test reads FALSE **because the thing it was
## looking for was present early enough to stop the reader**. Measured on whp02
## against the published cac-lsphp:php83: 5/5 runs status=141 with pipefail,
## 0 without.
##
## It reproduces on some hosts and not others, and the reason is the PIPE
## CAPACITY, not the payload alone. While the writer's whole output fits in the
## pipe it never blocks and always finishes before the reader can act; once it
## does not fit, the early exit is a guaranteed SIGPIPE. Linux gives a pipe
## 64 KiB by default — 40 KB fits, which is why this same image measured 0/10
## on the build host here — but drops NEW pipes to a single page once a user
## passes fs.pipe-user-pages-soft, which is the state a busy production host
## lives in. Forcing the payload over the limit makes it deterministic
## everywhere: 3x this output = 122100 bytes gave 141 141 141 in this very
## image. "It worked when I ran it" was never evidence about this bug.
##
## A here-string is not a pipeline at all: the shell materialises the whole
## string first (temp file, or a pipe only when it provably fits the pipe
## buffer) and the command's status is the reader's own status, so there is no
## second status for pipefail to prefer and no writer left alive to signal.
## `case`/`[[ ]]` would also avoid the pipeline, but would mean re-expressing an
## anchored line match as a glob over embedded newlines; keeping grep/awk with
## the SAME patterns makes this a plumbing change and nothing else.
##
## Both return the reader's status, so a genuinely-absent extension is still a
## clean 1 and a genuinely-missing "Scan this dir" line is still empty output.
lsphp_info_has_parity_ext() {
grep -q '^cac_path_parity support => enabled$' <<<"$1"
}
lsphp_info_scan_dir() {
awk -F'=> ' '/^Scan this dir/ {print $2; exit}' <<<"$1"
}
## Did `lsphp -i` answer at all? Separates "the extension is not there" from
## "our probe produced nothing to look in", so neither gets reported as the
## other. Keyed on the phpinfo banner, which is line 2 of every `lsphp -i`
## (verified against lsphp83 8.3.32) and is not something LSPHP_INFO could
## contain from any other source.
lsphp_info_is_usable() {
grep -q '^PHP Version => ' <<<"$1"
}
## ---- CAC-TEST: probe helpers END ----
PATH_PARITY_MODE="none"
LSPHP_INFO=$("$LSPHP_BIN" -i 2>/dev/null || true)
SCAN_DIR=$(printf '%s\n' "$LSPHP_INFO" | awk -F'=> ' '/^Scan this dir/ {print $2; exit}')
SCAN_DIR=$(lsphp_info_scan_dir "$LSPHP_INFO")
## `|| true` above is what keeps a broken probe survivable: fail-open is
## deliberate here and below — the site serves either way, only the $_SERVER
## strings differ. What the failure gets REPORTED as is handled at each of the
## two places it changes the outcome (the parity branch, and the no-scan-dir
## else at the bottom of this block).
if [ -n "$SCAN_DIR" ]; then
mkdir -p "$SCAN_DIR"
## Values emitted double-quoted via printf rather than interpolated into an
@@ -225,7 +284,7 @@ if [ -n "$SCAN_DIR" ]; then
## the request path is unaffected.
rm -f "$SCAN_DIR/99-cac-path-parity.ini" "$SCAN_DIR/99-cac-lsphp-normalize.ini"
PATH_PARITY_MODE="none (user/domain rejected)"
elif printf '%s\n' "$LSPHP_INFO" | grep -q '^cac_path_parity support => enabled$'; then
elif lsphp_info_has_parity_ext "$LSPHP_INFO"; then
{
echo '; rendered at container start by entrypoint-lsphp.sh'
printf 'cac_path_parity.from = "%s"\n' "$OLS_SITE_PATH"
@@ -241,12 +300,25 @@ if [ -n "$SCAN_DIR" ]; then
## where it failed to load). Restores the old, .user.ini-defeatable
## behaviour rather than losing normalisation entirely — but say so loudly,
## because in this mode parity is NOT guaranteed.
##
## FAIL-OPEN, DELIBERATELY: a probe that cannot answer must never stop the
## container. The site serves either way; only the $_SERVER strings differ.
cat > "$SCAN_DIR/99-cac-lsphp-normalize.ini" <<'EOF'
; rendered at container start by entrypoint-lsphp.sh (DEGRADED FALLBACK)
auto_prepend_file = /scripts/cac-lsphp-normalize.php
EOF
## ...but do not DIAGNOSE more than was established. The old wording said
## "extension not loadable in this image" for EVERY reason this branch is
## reached — including the probe breaking on its own, which is exactly what
## happened (see the SIGPIPE note on the helpers above): a false verdict
## that sent operators to rebuild an image whose extension was fine and
## whose build gate had passed. The claim now carries its evidence, and the
## evidence is real: reaching here at all means SCAN_DIR was parsed out of
## this same output, so `lsphp -i` did answer and its module list is
## authoritative. The case where it did NOT answer never gets here — it is
## caught and reported honestly at the `lsphp_info_is_usable` check above.
PATH_PARITY_MODE="auto_prepend (DEGRADED)"
echo "WARNING: entrypoint-lsphp: cac_path_parity extension not loadable in this image — falling back to the auto_prepend normaliser, which a site's own .user.ini auto_prepend_file will silently displace. Rebuild/repull cac-lsphp:php${PHPVER}." >&2
echo "WARNING: entrypoint-lsphp: cac_path_parity extension not loadable in this image — '${LSPHP_BIN} -i' answered (${#LSPHP_INFO} bytes, scan dir ${SCAN_DIR}) and does not list it — falling back to the auto_prepend normaliser, which a site's own .user.ini auto_prepend_file will silently displace. Rebuild/repull cac-lsphp:php${PHPVER}." >&2
fi
## Per-site opcache override (panel: Advanced Tuning → OpCache size); falls
## back to the baked lsphp-overrides.ini defaults when unset.
@@ -307,7 +379,19 @@ else
## No scan dir means none of the per-site ini drop-ins land — including the
## path-parity mapping. Previously this failed silently; it must not, because
## the tier's cac-fpm parity guarantee is one of the things lost.
echo "WARNING: entrypoint-lsphp: lsphp reports no additional-ini scan dir — per-site error_log, opcache and \$_SERVER path-parity settings were NOT applied." >&2
##
## Two different things land here and they are not the same report. "lsphp
## reports no additional-ini scan dir" ASSERTS that lsphp answered us, which
## is false when the probe produced nothing at all — and that was the wrong
## half of the same mistake the parity branch above made: describing a probe
## that could not answer as a finding about the image. Say which one it was.
if lsphp_info_is_usable "$LSPHP_INFO"; then
echo "WARNING: entrypoint-lsphp: lsphp reports no additional-ini scan dir — per-site error_log, opcache and \$_SERVER path-parity settings were NOT applied." >&2
PATH_PARITY_MODE="none (no scan dir)"
else
echo "WARNING: entrypoint-lsphp: '${LSPHP_BIN} -i' produced no usable phpinfo output (${#LSPHP_INFO} bytes) — per-site error_log, opcache and \$_SERVER path-parity settings were NOT applied. This is a PROBE failure and establishes nothing about what the image contains; run '${LSPHP_BIN} -i' in this container before concluding anything about it." >&2
PATH_PARITY_MODE="none (lsphp -i unusable)"
fi
fi
echo "entrypoint-lsphp: \$_SERVER path parity = ${PATH_PARITY_MODE} (${OLS_SITE_PATH} -> /home/${user})"