How to check OOM killer events in Linux

A process killed by the Linux OOM killer can look like a crash, a service restart, or a container exit with status 137. OOM kill evidence in the kernel log identifies the victim, the event time, and the memory context, within the limits of the records the host still retains.

On systemd hosts, journalctl keeps kernel messages alongside other logs, and --dmesg limits a search to those messages from the current boot unless another boot is named. A kernel OOM kill leaves a multi-line report ending in a Killed process line, and a severity filter removes part of it because the kernel logs the constraint line and task table at informational level. systemd-oomd is a separate userspace killer that logs through its own unit, so a clean kernel search does not rule it out on hosts that run it.

Do not force a production host into memory exhaustion just to test the query. A missing match means the accessible logs do not show an OOM kill for the selected boot or time window; it does not prove memory pressure never happened if the journal was rotated, the kernel ring buffer was overwritten, or a container runtime reported only its own cgroup event.

1. Search current-boot kernel messages for OOM killer entries.

   $ sudo journalctl --dmesg --boot --grep 'oom-kill|out of memory' --no-pager
   Nov 06 00:08:44 server kernel: sleep invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
   Nov 06 00:08:45 server kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/report-worker.service,task=report-worker,pid=1449,uid=1001
   Nov 06 00:08:45 server kernel: Out of memory: Killed process 1449 (report-worker) total-vm:2805816kB, anon-rss:2776728kB, file-rss:8kB, shmem-rss:0kB, UID:1001 pgtables:5496kB oom_score_adj:0

   The Killed process line names the victim and the time it was killed. The task before invoked oom-killer only made the memory request that failed, so sleep was not the process that died here. An -- No entries -- result means the journal holds no kernel OOM kill for this boot.
   Related: How to view system logs with journalctl

2. Check the previous boot when the process disappeared before the last restart.

   $ sudo journalctl --dmesg --boot -1 --grep 'oom-kill|out of memory' --no-pager
   Nov 05 22:58:56 server kernel: systemd-oomd invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=-900
   Nov 05 22:58:57 server kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/report-worker.service,task=report-worker,pid=1605,uid=1001
   Nov 05 22:58:57 server kernel: Out of memory: Killed process 1605 (report-worker) total-vm:2772136kB, anon-rss:2757400kB, file-rss:1588kB, shmem-rss:0kB, UID:1001 pgtables:5464kB oom_score_adj:0
   Nov 05 22:59:11 server kernel: thumbnail-worke invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
   Nov 05 22:59:12 server kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=/,mems_allowed=0,oom_memcg=/system.slice/thumbnail-worker.service,task_memcg=/system.slice/thumbnail-worker.service,task=thumbnail-worke,pid=1702,uid=1001
   Nov 05 22:59:12 server kernel: Memory cgroup out of memory: Killed process 1702 (thumbnail-worke) total-vm:281484kB, anon-rss:261524kB, file-rss:5956kB, shmem-rss:0kB, UID:1001 pgtables:588kB oom_score_adj:0

   CONSTRAINT_NONE with global_oom means the whole host ran out of memory. CONSTRAINT_MEMCG with Memory cgroup out of memory means a cgroup limit was reached, such as a service MemoryMax or a container memory limit, and task_memcg names the group the victim belonged to. A line that starts with systemd-oomd invoked oom-killer is still a kernel kill, because that daemon was only the task whose memory request failed. journalctl --list-boots shows which boots are still retained, and a journal kept only in memory holds just the current boot.

3. Print the full kernel report for the incident window.

   $ sudo journalctl --dmesg --boot all --since "2026-11-05 22:58:55" --until "2026-11-05 22:59:00" --no-pager
   Nov 05 22:58:56 server kernel: systemd-oomd invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=-900
   ##### snipped #####
   Nov 05 22:58:57 server kernel: Mem-Info:
   Nov 05 22:58:57 server kernel: active_anon:678573 inactive_anon:40924 isolated_anon:0
   ##### snipped #####
   Nov 05 22:58:57 server kernel: Free swap  = 0kB
   Nov 05 22:58:57 server kernel: Total swap = 0kB
   Nov 05 22:58:57 server kernel: 786432 pages RAM
   ##### snipped #####
   Nov 05 22:58:57 server kernel: Tasks state (memory values in pages):
   Nov 05 22:58:57 server kernel: [  pid  ]   uid  tgid total_vm      rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
   ##### snipped #####
   Nov 05 22:58:57 server kernel: [   1605]  1001  1605   693034   689747   689350      397         0  5595136        0             0 report-worker
   ##### snipped #####
   Nov 05 22:58:57 server kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/report-worker.service,task=report-worker,pid=1605,uid=1001
   Nov 05 22:58:57 server kernel: Out of memory: Killed process 1605 (report-worker) total-vm:2772136kB, anon-rss:2757400kB, file-rss:1588kB, shmem-rss:0kB, UID:1001 pgtables:5464kB oom_score_adj:0
   ##### snipped #####

   --since and --until take the time of the service restart, alert, or container exit under investigation, and --boot all lets that window reach earlier boots because --dmesg alone stays in the current boot.
   On the Killed process line, total-vm is the victim's virtual memory size, anon-rss is its private memory in RAM, file-rss is its file-backed memory in RAM, shmem-rss is its shared memory in RAM, and pgtables is the memory the kernel used for its page tables, all in kB. oom_score_adj is the adjustment applied to its OOM selection score.
   The Tasks state table lists memory in pages, except pgtables_bytes, and Free swap and Total swap show whether swap was available or already exhausted.

4. Read the current kernel ring buffer when the host has no accessible journal.

   $ sudo dmesg --kernel --time-format=iso | grep 'Killed process'
   2026-11-06T16:30:35,532458+00:00 Memory cgroup out of memory: Killed process 26633 (report-worker) total-vm:74108kB, anon-rss:64888kB, file-rss:1740kB, shmem-rss:0kB, UID:0 pgtables:184kB oom_score_adj:0
   2026-11-06T16:31:22,670579+00:00 Memory cgroup out of memory: Killed process 41945 (report-worker) total-vm:74920kB, anon-rss:60592kB, file-rss:3936kB, shmem-rss:0kB, UID:0 pgtables:176kB oom_score_adj:0

   dmesg covers only the current boot, and new messages overwrite the oldest ones. Plain sudo dmesg --kernel --time-format=iso output holds the full report above that line. dmesg -t removes the timestamps that give the event time. On an Ubuntu host running rsyslog, sudo grep --text 'Killed process' /var/log/kern.log reads the copy kept on disk.

5. Search systemd-oomd logs when the kernel search finds no kill.

   $ sudo journalctl --unit systemd-oomd.service --boot --grep 'killed' --no-pager
   Nov 06 00:09:05 server systemd-oomd[604]: Killed /batch.slice/cache-warmer.service due to memory pressure for /batch.slice being 26.58% > 10.00% for > 5s with reclaim activity

   systemd-oomd kills a whole control group when memory pressure or swap use stays over its limits, and its kills do not appear as kernel OOM messages. The log line names the group and the pressure reading behind the kill.

6. Compare the OOM timestamp with the affected systemd service when the victim was service-managed.

   $ sudo systemctl status --no-pager report-worker.service
   × report-worker.service - Report Worker
        Loaded: loaded (/etc/systemd/system/report-worker.service; disabled; preset: enabled)
        Active: failed (Result: oom-kill) since Fri 2026-11-06 00:08:47 UTC; 7min ago
      Duration: 1min 12.564s
    Invocation: 2f4664aa587540b5a7dade002756828e
       Process: 1449 ExecStart=/usr/local/bin/report-worker (code=killed, signal=KILL)
      Main PID: 1449 (code=killed, signal=KILL)
      Mem peak: 2.6G
           CPU: 18.952s
   
   Nov 06 00:07:31 server systemd[1]: Started report-worker.service - Report Worker.
   Nov 06 00:08:44 server systemd[1]: report-worker.service: The kernel OOM killer killed some processes in this unit.
   Nov 06 00:08:47 server systemd[1]: report-worker.service: Main process exited, code=killed, status=9/KILL
   Nov 06 00:08:47 server systemd[1]: report-worker.service: Failed with result 'oom-kill'.
   Nov 06 00:08:47 server systemd[1]: report-worker.service: Consumed 18.952s CPU time over 1min 15.958s wall clock time, 2.6G memory peak.

   Result: oom-kill appears after kernel and systemd-oomd kills alike, so the log line beneath it names the killer. A line naming systemd-oomd is a userspace kill, and a line naming the OOM killer without systemd-oomd is a kernel kill, which older systemd releases log as A process of this unit has been killed by the OOM killer. signal=KILL or container exit status 137 alone does not prove an OOM kill, so treat the matching kernel Out of memory or oom-kill line as the proof.
   Related: How to check Linux service status