LFCS Operation of Running Systems Practice Question
A system running RHEL 8 experiences intermittent crashes. After reboot, 'journalctl -p err -b -1' outputs: 'PID 1234 (myapp) ended due to signal: KILL'. Which diagnostic step should the administrator perform next?
⚠ Common exam trap
Many exam-takers confuse 'signal: KILL' with a manual kill command or a segmentation fault, leading them to choose core dumps (C) or strace (B), when the specific signal name 'KILL' (SIGKILL) points directly to the OOM killer or an explicit kill -9, and the OOM killer is the most common cause in intermittent crash scenarios.
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
✓
Check journalctl for 'oom-kill' entries or use 'dmesg | grep -i oom'.
The 'PID ended due to signal: KILL' message indicates the process was terminated by a SIGKILL (signal 9), which is commonly sent by the Out-Of-Memory (OOM) killer when the system runs low on memory. Checking journalctl for 'oom-kill' entries or using 'dmesg | grep -i oom' directly confirms whether the OOM killer was responsible, making D the correct next diagnostic step.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Review logrotate configuration for myapp logs.
Why it's wrong here
Logrotate only rotates and compresses application log files; it never sends signals to running processes, so it cannot explain a SIGKILL. Reviewing logrotate is correct when logs vanish, grow unbounded, or rotation scripts fail, not for process termination.
- ✗
Run strace to capture system calls of myapp before restarting.
Why it's wrong here
Signal KILL indicates the kernel or OOM killer terminated the process, so strace cannot observe it; the process is already gone before tracing begins. strace is correct for diagnosing a running process that misbehaves, such as hanging on a syscall or file descriptor error.
- ✗
Enable core dumps and reproduce issue.
Why it's wrong here
A core dump captures memory state at crash time, but SIGKILL terminates the process without producing one, so reproduction yields nothing. Enabling core dumps is correct for SIGSEGV or SIGABRT faults, where the kernel dumps the address space on abnormal termination.
- ✓
Check journalctl for 'oom-kill' entries or use 'dmesg | grep -i oom'.
Why this is correct
SIGKILL combined with intermittent crashes points to the kernel OOM killer terminating myapp. Checking journalctl for oom-kill entries or grepping dmesg confirms whether memory exhaustion, not an application fault, caused the kill, directing the next diagnostic step.
Go deeper
Related to this question
About these practice questions
Courseiva writes every LFCS question from scratch — 406 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.