2 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Claude	433e74975c	fix(cac-lsphp): enable .user.ini support (LSPHP_ENABLE_USER_INI) ... php-lsapi compiles .user.ini support in but leaves it DISABLED by default. sapi/litespeed/lsapi_main.c has `static int parse_user_ini = 0;` and only sets it when the process environment contains LSPHP_ENABLE_USER_INI=on. WHP never set it, so lsphp never entered the user-ini chain at all. The failure was silent: phpinfo() still reports user_ini.filename=.user.ini and user_ini.cache_ttl=300, because those are core INI defaults that are simply inert under this SAPI. Every other WHP PHP tier (cac, cac-fpm, cac-litespeed) honors .user.ini, so shared_ols was quietly inconsistent. Impact found in production (whp01/whp02/sdbees/TrueSelfCA, 29 sites): - Per-site memory_limit / max_input_vars overrides were ignored. A Divi site's max_input_vars stayed at the 2000 default while its .user.ini asked for 20000. - Wordfence's auto_prepend_file WAF never loaded on ANY shared_ols site. 11 sites had the plugin installed and reporting "Extended Protection" enabled while the prepend was never executed. Verified on a live sidecar (shadowdao.com, whp01) before this commit by injecting the env var via whp.container_types.startup_env and recreating: before: auto_prepend_file=/scripts/cac-lsphp-normalize.php (WAF absent) after: auto_prepend_file=/home/shadowdao/public_html/wordfence-waf.php wordfence-waf.php present in get_included_files() class_exists('wfWAF') === true The platform normalize prepend still chains in behind Wordfence's bootstrap, so DOCUMENT_ROOT canonicalisation is not lost. Set in two places on purpose: the Dockerfile ENV makes the value visible in `docker inspect` and survives an entrypoint override, and the entrypoint re-exports it with the same default because the runuser fallback exec path resets the environment. Still overridable per-container (LSPHP_ENABLE_USER_INI=off) as an escape hatch for a site whose legacy cPanel-generated .user.ini has not been remediated yet. NOTE: enabling this activates every previously-inert .user.ini at once. Audit the fleet for stale cPanel directives before rolling this image — session.save_path values under /var/cpanel/ that do not exist in the container, memory_limit above the cgroup cap, and upload_max_filesize values below the platform default were all found and remediated first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 15:23:05 -07:00
Claude Code	1756d496e5	detect-memory: raise PHP_WORKER_ESTIMATE_MB default 60→128 ... The 60 MB worker estimate was optimistic for plugin-heavy WordPress and WooCommerce stacks. Concrete measurement on alphaone 2026-06-01: Container memory : 1024 MiB (later 2048 MiB) Pool sized by formula : pm.max_children = (1024-100)/60 = 15 Actual per-worker RSS : ~193 MB (anon+file+shmem from kernel OOM dumps) Worst-case peak : 15 × 193 MB ≈ 2.9 GB That math put traffic-burst peak demand well over the container cap, producing 1,586 cumulative oom_kills across alphaone's two containers over 18 days and intermittent fork-starvation for unrelated tenants on the host. 128 MB is a more realistic baseline: closer to actual WP+Woo+page- builder worker footprint, still conservative enough that lighter sites continue to get reasonable concurrency. The matrix at common container tiers: Tier (MiB) | old children | new children | new peak demand 256 | 2 (floored) | 2 (floored) | ~256 MB 512 | 6 | 3 | ~384 MB 768 | 11 | 5 | ~640 MB 1024 | 15 | 7 | ~896 MB 2048 | 15 (capped*) | 15 | ~1.9 GB (* old formula returned 32 at 2 GiB but production containers were booted at lower tiers and never recalculated; see whp01 audit.) Existing containers keep their boot-time pm.max_children until they are recreated — this change only affects new containers. Customers or operators can override per-container via FPM_MAX_CHILDREN env.	2026-06-01 08:23:09 -07:00