Back to All Scenarios
PASSEDqueue / container_crash
Pulsar 3.2 Container OOM Killed — Memory Limit Hit on AlmaLinux 9
Pulsar 3.2 running in a container was OOM killed due to exceeding its memory limit. Container restarting in a loop.
Pattern
CONTAINER_EVENT
Severity
HIGH
Confidence
68%
Remediation
Auto-Heal
Test Results
| Metric | Expected | Actual | Result |
|---|---|---|---|
| Pattern Recognition | CONTAINER_EVENT | CONTAINER_EVENT | |
| Severity Assessment | HIGH | HIGH | |
| Incident Correlation | N/A | None | |
| Cascade Escalation | N/A | No | |
| Remediation | — | Auto-Heal — Corax resolves autonomously |
Scenario Conditions
AlmaLinux 9. Pulsar 3.2 container memory limit 12GB. Container RSS exceeded limit. Docker/K8s OOM killed the container. Restart count increasing.
Injected Error Messages (1)
Pulsar 3.2 container restart on AlmaLinux 9 — container oomkilled by docker/kubernetes, memory limit 12GB exceeded, OOMKilled: true, container restart loop, pulsar crash
Neural Engine Root Cause Analysis
Container runtime event detected — a container has been OOM-killed due to memory limits, an image pull has failed preventing container startup, or the container runtime itself is experiencing issues. Container failures can cascade in orchestrated environments where dependent services rely on the affected container.
Remediation Plan
1. For OOM-killed containers, review memory limits in the container spec and increase if the application legitimately needs more memory.
2. For image pull failures, verify the container registry is reachable, credentials are valid, and the image tag exists.
3. Check container logs with 'docker logs <container-id>' for application-level errors before the crash.
4. Verify disk space on the container host — full disks prevent image pulls and container operations.
5. For runtime issues, check the Docker daemon logs ('journalctl -u docker') and consider restarting the daemon if unresponsive.
Tested: 2026-04-02Monitors: 1 | Incidents: 1Test ID: cmnhnwa5804e0lijgsnukwo92