Enabling Core Dumps for LiteSpeed / OpenLiteSpeed (LSPHP)

When PHP crashes unexpectedly, a core dump captures the exact memory state of the process at the moment it died. Monarx engineering uses these files to produce a backtrace and pinpoint the root cause. This guide covers servers running LiteSpeed Web Server (LSWS Enterprise) or OpenLiteSpeed, where PHP runs as external lsphp processes — common on cPanel/CloudLinux and other LiteSpeed‑based hosts.

Confirm you're on LiteSpeed:

Seeing lsphp processes means PHP is served by LiteSpeed — continue below.

On LiteSpeed, lsphp workers are spawned by the web server (lshttpd) and run under the site's suEXEC user. They inherit resource limits from the lshttpd service, so raising the limit on the service is what enables core dumps for every lsphp child.

The LiteSpeed service/control names differ by edition:

The lsphp children inherit limits from lshttpd. Create a systemd override on the service:

Add:

Then reload systemd and restart LiteSpeed (this respawns all lsphp workers so they pick up the new limit):

⚠️ If LiteSpeed is not managed by systemd (started directly via lswsctrl), set the limit in the startup environment instead — add ulimit -c unlimited to /usr/local/lsws/bin/lswsctrl before the start logic, or to the init script that launches it, then restart with lswsctrl restart.

Define where the kernel writes cores and how they're named. Add to /etc/sysctl.conf:

The placeholders expand to %e executable name, %p PID, %h hostname, and %t timestamp. Apply it without rebooting:

💡 Why /tmp? lsphp runs as the site's unprivileged suEXEC user, so the destination must be writable by that user. /tmp (sticky, world‑writable) is the most reliable target across many accounts. See the CloudLinux note below if you use CageFS.

If you point the pattern at a dedicated directory instead of /tmp, make it world‑writable with the sticky bit so any suEXEC user can write but only owners can delete:

…and update kernel.core_pattern in step 2 to /var/log/lsphp-cores/core-%e.%p.%h.%t, then re‑run sysctl -p.

⚠️ cPanel + CloudLinux / CageFS: Each account runs inside its own virtualized filesystem, so a core written to /tmp lands in that account's /tmp (/home/virtfs/<user>/tmp/ from the host). Keeping the pattern in /tmp is simplest. If you target a custom host path, add it to CageFS and remount:

Note that an absolute kernel.core_pattern is a host‑level setting and applies to all accounts.

Find a running lsphp worker and send it SIGSEGV (signal 11). LiteSpeed respawns lsphp on the next request — no lasting impact:

Confirm a core file appeared (check the account's /tmp on CloudLinux):

You should see a file like core-lsphp.12345.web01.1719600000. If nothing appears, re‑check steps 1–3 — most often LimitCORE wasn't applied because LiteSpeed was not fully restarted, or the destination isn't writable by the suEXEC user.

Core files can be large — compress before sending:

Send the compressed file to support@monarx.com or via the dashboard chat, and include:

Monarx engineering will run a backtrace analysis, identify the root cause, and recommend a fix.