Your terminal just printed the word "Killed." No stack trace, no error code, just one word and your process is gone. You check free -h out of habit and the server has 32 GB, 64 GB, even 128 GB free. So why did Linux kill your process on a machine with plenty of memory to spare?
This happens constantly on hosting servers — a WordPress import stalls mid-upload, a Node script dies during a build, a backup job vanishes without a log entry. The cause is almost never "the server ran out of RAM." It is almost always a limit that was never visible to you in the first place. Here is how to find the real limit and fix it, both from the command line and directly in Panelica.
Why does Linux kill a process when there is free RAM?
Two completely different mechanisms produce the word "Killed," and they need two different fixes:
- The Linux OOM killer steps in when the memory available to a specific scope — not necessarily the whole machine — is exhausted. If your process is running inside a cgroup with a memory ceiling (which every Panelica hosting account is), the OOM killer can fire the moment that account's ceiling is reached, regardless of how much RAM the physical server has left.
- PHP's own memory_limit produces a different, more polite failure: a fatal error reading
Allowed memory size of 268435456 bytes exhausted. This is PHP refusing to allocate more memory than its ownphp.inisetting allows, independent of any OS-level limit.
Check dmesg for the real reason
Before changing anything, find out which of the two actually happened:
If you see Memory cgroup out of memory, the fix is raising your account's resource limit, not the PHP setting. If instead your browser or upload showed Allowed memory size of X bytes exhausted, the fix is the PHP memory_limit value, and it is the more common case for a WordPress site.
Why "free -h" shows free RAM but your app still gets killed
On many hosting platforms, free -h inside your own account reports the server's total physical memory, even though your account is actually capped far below that by a cgroup you cannot see. That mismatch is exactly what makes this confusing: the number on screen says 128 GB free, the kill message says out of memory, and the two seem to contradict each other.
Panelica closes that gap with LXCFS: free -m, nproc, and similar commands report your account's actual cgroup limit, not the host total. If your plan is capped at 2 GB, free -m shows roughly 2 GB, not the server's full capacity. The number you see is the number that governs you, which is also why applications that size themselves off free -m — a JVM, a Node process, a self-managed PostgreSQL instance — size themselves correctly on Panelica instead of assuming they own the whole physical machine.
Case 1: PHP says "Allowed memory size exhausted"
This is the classic WordPress scenario: uploading a large theme or plugin zip through the panel's File Manager, or running a bulk import, and PHP stops with a memory-exhausted fatal error. The fix is a per-domain PHP setting, and it takes effect without any server restart:
memory_limit in the pool settings and raise it, for example from 256M to 512M.memory_limit for one domain never changes the limit for another customer's site on the same server.
Case 2: dmesg says "Memory cgroup out of memory"
This means the process needed more memory than your account's cgroup ceiling allows, and no PHP setting can fix it — the kill happened below PHP, at the kernel level. Two paths, depending on who you are:
- If you are on a shared or reseller-provisioned account, go to Users → (your account) → Resource Limits in the panel, or ask whoever manages the server to raise the memory cgroup limit or move you to a plan with more RAM.
- If you own the VPS or dedicated server yourself, you are the only tenant, so the cgroup ceiling is a safety default rather than a shared-hosting boundary. Raise it directly from Users → Resource Limits, or confirm the server itself has enough physical RAM for what you are running.
Check your live limit before you get killed again
Because free -m on Panelica reports your actual account limit, you can watch it approach the ceiling before a process gets killed, instead of finding out after the fact from a log message.
Frequently asked questions
Why does Linux kill my process even though there is free RAM on the server?
Your process almost always runs inside a cgroup with its own memory ceiling, separate from the server's total RAM. The OOM killer enforces that ceiling, not the physical machine's total memory. Check dmesg for "Memory cgroup out of memory" to confirm.
What does "Memory cgroup out of memory" mean?
It means the process that was killed exceeded the memory limit assigned to its cgroup — on a hosting account, that is usually the account's plan limit, not a server-wide shortage.
How do I increase PHP's memory_limit safely?
In Panelica, open PHP Manager, select the domain, and raise memory_limit in that domain's PHP-FPM pool settings. The change applies only to that domain's pool and reloads without downtime.
Does raising memory_limit for one site affect other sites on the same server?
No. Panelica runs a separate PHP-FPM pool per account per PHP version, so a memory_limit change for one domain has no effect on any other account's pool.
If you manage your own VPS
On a self-managed VPS or dedicated server, you are the only tenant, so per-version PHP-FPM pools and one-click PHP version switching exist to make tuning fast rather than to separate you from anyone else. Panelica's PHP Manager and OPcache controls let you change memory_limit, switch PHP versions per domain, and watch real resource usage without editing configuration files by hand or polluting the host system's own PHP installation.