LFCS Operation of Running Systems Practice Question
After a kernel update, a service fails to start with 'cannot allocate memory'. The system has 16GB RAM and 8GB swap. Which command should the administrator run first to diagnose potential memory limits?
⚠ Common exam trap
The trap here is that candidates see 'cannot allocate memory' and immediately think of system memory exhaustion, leading them to choose `free -m` or `/proc/meminfo`, but the LFCS exam tests the distinction between system-wide memory and per-process resource limits enforced by `ulimit`.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
ulimit -a
`ulimit -a` displays all current user-level resource limits, including `max memory size`, `max processes`, and `max locked memory`. After a kernel update, the service may be hitting a newly enforced or reduced `ulimit` (e.g., `RLIMIT_AS` or `RLIMIT_DATA`), which can cause 'cannot allocate memory' even when system memory is abundant. This command is the fastest way to check if a per-process limit is the culprit.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
free -m
Why it's wrong here
free -m reports total, used and available RAM and swap, but not the per-process or cgroup limits that trigger 'cannot allocate memory' after a kernel update. It is tempting because it is the standard first look at memory pressure; systemd unit limits or cgroup memory.max values are the actual constraint here.
- ✓
ulimit -a
Why this is correct
ulimit -a prints all current shell resource limits, including virtual memory and max memory size, revealing whether a restrictive cap prevents the service from allocating memory despite ample physical RAM and swap. It is the fastest first diagnostic step.
- ✗
cat /proc/meminfo
Why it's wrong here
/proc/meminfo shows system-wide memory counters, not the per-service cgroup or systemd limit that produces 'cannot allocate memory'. It is tempting as a general memory overview, yet the service's own MemoryMax or cgroup memory.max is the binding constraint. Inspect the unit's limits directly rather than aggregate host figures.
- ✗
sysctl vm.overcommit_memory
Why it's wrong here
vm.overcommit_memory governs kernel allocation heuristics, not the cgroup or systemd MemoryMax ceiling that a service hits. It is tempting because overcommit settings can cause allocation failures, but reading it first ignores the per-unit limits introduced or changed by the kernel update. Check systemctl show or cgroup memory.max instead.
Go deeper
Related to this question
About these practice questions
One of 406 original LFCS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.