Diagnose & Fix Persistent 500 Error — Zen Cart / Apache / PHP-FPM (Linux Server Level)
Budget / Salary$30–250
TypeFreelance project
LocationRemote
Posted1 hour ago
Our Zen Cart 1.5.7c e-commerce site (PHP 8.2, Apache/Plesk, MariaDB) is returning an HTTP 500 error on the home page and category pages. We need an experienced Linux/Apache/PHP-FPM engineer to find and fix the root cause.
This is a server infrastructure diagnosis job, not a typical "fix my Zen Cart" job. We've already done extensive testing and ruled out the application code as the cause. We need someone comfortable tracing requests at the web-server/PHP-FPM layer, not someone who will start by reinstalling Zen Cart or clearing caches.
WHAT WE'VE ALREADY DONE (please read before bidding):
Fixed a MySQL connection-limit issue that was causing a separate, unrelated batch of errors (confirmed resolved).
Enabled Zen Cart's file-based error logging, which was previously silently disabled, and confirmed it is now capturing real warnings in real time.
Confirmed, via four separate command-line reproductions of the exact failing page, that the Zen Cart PHP code itself runs successfully every time. No PHP fatal error or exception has ever been logged for the failing request, despite the failure being currently 100% reproducible in the browser.
Confirmed via a live strace that the PHP-FPM worker process exits cleanly during a failure, with no crash signal.
Ruled out: memory limits, opcache, database corruption, open_basedir restrictions, ModSecurity, nginx (not running on this server), and Apache module conflicts.
Confirmed the Unix socket between Apache and PHP-FPM is stable and present throughout a failing request.
Our working conclusion is that the fault is happening in the Apache-to-PHP-FPM request handoff itself, not inside the application. This has not been directly confirmed yet and is the specific gap we need a specialist to close.
A full written incident report with all test results, findings, and things already ruled out will be provided to the freelancer we hire, so you can go straight to the unsolved part instead of repeating work we've done.
WHAT YOU'LL NEED TO DO:
Review our incident report and existing findings.
Use root/SSH access (which we'll provide) to directly trace a live failing request at the Apache/proxy_fcgi/PHP-FPM boundary — for example using strace on the Apache worker process itself, Apache's trace-level logging for mod_proxy_fcgi, or similar tools.
Identify the specific point and cause of failure.
Implement and verify a fix.
Write up what was found and fixed in plain language for a non-technical business owner.
DELIVERABLES:
Root cause of the 500 error identified and documented
Fix implemented and confirmed (home page and category pages load correctly and consistently, tested under real traffic, not just a single reload)
Payment Modules "edit" link restored to working order (secondary task)
Short plain-language write-up of what was wrong and what was changed
This is a server infrastructure diagnosis job, not a typical "fix my Zen Cart" job. We've already done extensive testing and ruled out the application code as the cause. We need someone comfortable tracing requests at the web-server/PHP-FPM layer, not someone who will start by reinstalling Zen Cart or clearing caches.
WHAT WE'VE ALREADY DONE (please read before bidding):
Fixed a MySQL connection-limit issue that was causing a separate, unrelated batch of errors (confirmed resolved).
Enabled Zen Cart's file-based error logging, which was previously silently disabled, and confirmed it is now capturing real warnings in real time.
Confirmed, via four separate command-line reproductions of the exact failing page, that the Zen Cart PHP code itself runs successfully every time. No PHP fatal error or exception has ever been logged for the failing request, despite the failure being currently 100% reproducible in the browser.
Confirmed via a live strace that the PHP-FPM worker process exits cleanly during a failure, with no crash signal.
Ruled out: memory limits, opcache, database corruption, open_basedir restrictions, ModSecurity, nginx (not running on this server), and Apache module conflicts.
Confirmed the Unix socket between Apache and PHP-FPM is stable and present throughout a failing request.
Our working conclusion is that the fault is happening in the Apache-to-PHP-FPM request handoff itself, not inside the application. This has not been directly confirmed yet and is the specific gap we need a specialist to close.
A full written incident report with all test results, findings, and things already ruled out will be provided to the freelancer we hire, so you can go straight to the unsolved part instead of repeating work we've done.
WHAT YOU'LL NEED TO DO:
Review our incident report and existing findings.
Use root/SSH access (which we'll provide) to directly trace a live failing request at the Apache/proxy_fcgi/PHP-FPM boundary — for example using strace on the Apache worker process itself, Apache's trace-level logging for mod_proxy_fcgi, or similar tools.
Identify the specific point and cause of failure.
Implement and verify a fix.
Write up what was found and fixed in plain language for a non-technical business owner.
DELIVERABLES:
Root cause of the 500 error identified and documented
Fix implemented and confirmed (home page and category pages load correctly and consistently, tested under real traffic, not just a single reload)
Payment Modules "edit" link restored to working order (secondary task)
Short plain-language write-up of what was wrong and what was changed
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.