What killed my process and why?

Asked 7/4, 2009 at 17:7 Answered 30/12, 2018 at 0:58

814

My application runs as a background process on Linux. It is currently started at the command line in a Terminal window.

Recently a user was executing the application for a while and it died mysteriously. The text:

Killed

was on the terminal. This happened two times. I asked if someone at a different Terminal used the kill command to kill the process? No.

Under what conditions would Linux decide to kill my process? I believe the shell displayed "killed" because the process died after receiving the kill(9) signal. If Linux sent the kill signal should there be a message in a system log somewhere that explains why it was killed?

Haase answered 7/4, 2009 at 17:7 Comment(6)

linux killed my process and logged it in /var/log/messages on redhat – Polyvalent 18/9, 2013 at 12:45

See also this answer on unix.stackexchange.com. – Tony 28/12, 2014 at 21:6

There are 3 players in this event: (1) The process which (common cause) takes too much memory and causes the OOM condition (2) The kernel which sends the SIGKILL (signal 9) to terminate it and logs the fact in some system log like /var/log/messages (3) The shell under which the process ran which is the process that prints the Killed notification when the exit status from waitpid(2) indicates the child process died from signal 9. – Estancia 18/12, 2019 at 5:39

After reading @DeanHiller's answer, I found log messages on Ubuntu under /var/log/syslog – Sherrod 24/2, 2020 at 23:37

Related: How do I disable the systemd OOM process killer in Ubuntu 22.04? – Seacoast 23/9, 2022 at 17:16

@DeanHiller It was /var/log/kern.log for me. – Quintanilla 21/3 at 17:22

497

If the user or sysadmin did not kill the program the kernel may have. The kernel would only kill a process under exceptional circumstances such as extreme resource starvation (think mem+swap exhaustion).

Efficiency answered 7/4, 2009 at 17:23 Comment(14)

If the kernel killed the process would it put a message in a log somewhere? – Haase 7/4, 2009 at 17:29

I just wrote a program that malloc'd memory in an inifite loop. After the system got slow, "Killed" was displayed in the terminal and the process was terminated. The file /var/log/kern.log contained a lot of info about the termination. -Thanks for the pointer. – Haase 7/4, 2009 at 17:49

That's almost definitely it. I saw this a lot when TAing. Many students would forget to free their objects, and the apps would eventually reach 3GB of virtual memory usage. As soon as it hit that point it was killed. – Talmudist 7/4, 2009 at 19:3

Does the OS actually kill the process or does the program simply crash? I think allocating memory when nothing is available is a fatal error in C++. – Grimmett 12/5, 2010 at 14:54

The OS will actually kill the process, regardless of the language used. Failure to allocate memory is handled in various ways in various languages, but typically it's a matter of handling an exception or checking return status. This won't help if you've successfully allocated memory and the OOM killer targets you. – Efficiency 13/5, 2010 at 20:41

The OOM killer strikes again! – Divisor 22/7, 2011 at 0:36

When the "program simply crashes", that is the OS actually killing the process! – Wenwenceslaus 23/11, 2011 at 13:11

Here is a good article on how to protect your process from being killed: backdrift.org/how-to-create-oom-killer-exceptions – Vital 16/8, 2012 at 0:10

Use dmesg to see kernel log: here I find my python processes killed by kernel due to extreme virtual memory consumption. – Meyerbeer 28/8, 2013 at 7:43

@BerndJendrissek: Some "program simply crashes" are hidden calls to terminate, I don't know if that counts as the OS killing it. – Geosphere 14/3, 2014 at 21:1

It's the kernel OOM killer. Took me a while to find this article. oracle.com/technetwork/articles/servers-storage-dev/… – Drava 9/10, 2014 at 7:0

Once I find the log in kernel.log, it was killed by OOM killer. – Izolaiztaccihuatl 21/5, 2015 at 1:57

Is there any way to prevent it, and kill the program gracefully? – Odilia 8/2, 2016 at 23:35

@Grimmett this is impossible in Linux. In Linux, the kernel will always return true when you call malloc, and it will simply try to find ways of giving all processes the memory they need, whether it's by swapping or by some other means. In extreme circumstances, such as apparently in this case, the kernel will kill a process. At no point does the program/programmer get any indication anything is wrong. – Physiologist 4/4, 2018 at 12:40

434

Try:

dmesg -T| grep -E -i -B100 'killed process'

Where -B100 signifies the number of lines before the kill happened.

Omit -T on Mac OS.

Cyrenaica answered 19/12, 2013 at 2:59 Comment(5)

FYI, from info egrep: "egrep is the same as grep -E. ... Direct invocation as either egrep or fgrep is deprecated" – Hypophosphate 21/5, 2014 at 15:49

In the case of a simple pattern like 'killed process' you can just use grep instead of egrep with no other changes. For a more complex pattern, you would change replace e.g. egrep -i -B100 'foo|ba[rz]' with grep -E -i -B100 'foo|ba[rz]'. This Q&A gives more detail. – Hypophosphate 22/5, 2014 at 15:10

I'd also suggest using dmesg -T in order to get readable timestamps – Chinachinaberry 22/11, 2017 at 11:5

If you only want to see a list of recently killed process on a server, try using dmesg -T| grep -E 'Killed process' – Blitz 19/6, 2020 at 14:43

Please be aware that the dmesg command only displays messages stored in the kernel ring buffer. If you are searching for OOM (Out of Memory) messages, they could potentially be overwritten and might not be accessible via the dmesg command. You will need to search in other locations like /var/log/kern.log or /var/log/messages – Debor 15/8, 2023 at 11:57

198

This looks like a good article on the subject: Taming the OOM killer (1).

The gist is that Linux overcommits memory. When a process asks for more space, Linux will give it that space, even if it is claimed by another process, under the assumption that nobody actually uses all of the memory they ask for. The process will get exclusive use of the memory it has allocated when it actually uses it, not when it asks for it. This makes allocation quick, and might allow you to "cheat" and allocate more memory than you really have. However, once processes start using this memory, Linux might realize that it has been too generous in allocating memory it doesn't have, and will have to kill off a process to free some up. The process to be killed is based on a score taking into account runtime (long-running processes are safer), memory usage (greedy processes are less safe), and a few other factors, including a value you can adjust to make a process less likely to be killed. It's all described in the article in a lot more detail.

Edit: And here is [another article] (2) that explains pretty well how a process is chosen (annotated with some kernel code examples). The great thing about this is that it includes some commentary on the reasoning behind the various badness() rules.

Findlay answered 7/4, 2009 at 17:51 Comment(4)

I really love the article links. I'd suggest anyone who's interested in the topic to read them -- especially the comments on the lwn article. – Oilbird 15/3, 2011 at 15:33

"Linux will give it that space, even if it is claimed by another process" That's not quite how virtual memory works... – Geosphere 14/3, 2014 at 21:2

the article is quite old (2009) and not all functionality suggested in the article is in mainline. – Flycatcher 26/4, 2018 at 9:7

Related: How do I disable the systemd OOM process killer in Ubuntu 22.04? – Seacoast 23/9, 2022 at 17:17

Let me first explain when and why OOMKiller get invoked?

Say you have 512 RAM + 1GB Swap memory. So in theory, your CPU has access to total of 1.5GB of virtual memory.

Now, for some time everything is running fine within 1.5GB of total memory. But all of sudden (or gradually) your system has started consuming more and more memory and it reached at a point around 95% of total memory used.

Now say any process has requested large chunck of memory from the kernel. Kernel check for the available memory and find that there is no way it can allocate your process more memory. So it will try to free some memory calling/invoking OOMKiller (http://linux-mm.org/OOM).

OOMKiller has its own algorithm to score the rank for every process. Typically which process uses more memory becomes the victim to be killed.

Where can I find logs of OOMKiller?

Typically in /var/log directory. Either /var/log/kern.log or /var/log/dmesg

Hope this will help you.

Some typical solutions:

Increase memory (not swap)
Find the memory leaks in your program and fix them
Restrict memory any process can consume (for example JVM memory can be restricted using JAVA_OPTS)
See the logs and google :)

Adorno answered 5/4, 2016 at 0:36 Comment(0)

This is the Linux out of memory manager (OOM). Your process was selected due to 'badness' - a combination of recentness, resident size (memory in use, rather than just allocated) and other factors.

sudo journalctl -xb

You'll see a message like:

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

Avoidance answered 20/7, 2015 at 12:56 Comment(3)

How can I find out the memory deficit amount? – Purine 16/4, 2021 at 10:38

@Purine it depends on the amount of data - normally you'd have a heap snapshot of the process (which depends on the programming language / VM used). But the answer may be - "the deficit is infinite, because you have a memory leak" - eg you're adding to an array you're using, and it just gets bigger the longer your program runs. – Avoidance 16/4, 2021 at 10:41

Just a note, if you add grep like so: sudo journalctl -xb | grep "Killed process <process id>" it will display just the lines about killing the process you're interested in. – Birgit 13/2, 2023 at 15:0

As dwc and Adam Jaskiewicz have stated, the culprit is likely the OOM Killer. However, the next question that follows is: How do I prevent this?

There are several ways:

Give your system more RAM if you can (easy if its a VM)
Make sure the OOM killer chooses a different process.
Disable the OOM Killer
Choose a Linux distro which ships with the OOM Killer disabled.

I found (2) to be especially easy to implement:

Adjust /proc/<PID>/oom_score_adj to -1000 (which automatically takes oom_adj to -17 and oom_score to 0).

See how To Create OOM Exclusions in Linux for more.

Giarla answered 28/1, 2014 at 19:1 Comment(3)

It was the RAM for me. I upgraded from 2 to 4GB RAM and problem gone. Now the problem is with the bill :P – Exhibit 24/10, 2019 at 13:52

Way #2: The article was useful but it's outdated. You should now adjust /proc/<PID>/oom_score_adj to -1000 (which automatically takes oom_adj to -17 and oom_score to 0, so your process never gets killed) – Plusch 2/12, 2020 at 9:57

@Plusch excellent comment, I've added that to the answer since the article was outdated. – Avoidance 14/2, 2023 at 10:4

A tool like systemtap (or a tracer) can monitor kernel signal-transmission logic and report. e.g., https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap --example sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

The filtering if block in that script can be adjusted to taste, or eliminated to trace systemwide signal traffic. Causes can be further isolated by collecting backtraces (add a print_backtrace() and/or print_ubacktrace() to the probe, for kernel- and userspace- respectively).

Jerald answered 25/2, 2015 at 17:59 Comment(0)

The PAM module to limit resources caused exactly the results you described: My process died mysteriously with the text Killed on the console window. No log output, neither in syslog nor in kern.log. The top program helped me to discover that exactly after one minute of CPU usage my process gets killed.

Dibru answered 26/4, 2012 at 19:20 Comment(0)

In an lsf environment (interactive or otherwise) if the application exceeds memory utilization beyond some preset threshold by the admins on the queue or the resource request in submit to the queue the processes will be killed so other users don't fall victim to a potential run away. It doesn't always send an email when it does so, depending on how its set up.

One solution in this case is to find a queue with larger resources or define larger resource requirements in the submission.

You may also want to review man ulimit

Although I don't remember ulimit resulting in Killed its been a while since I needed that.

Horseradish answered 3/3, 2012 at 7:7 Comment(0)

In my case this was happening with a Laravel queue worker. The system logs did not mention any killing so I looked further and it turned out that the worker was basically killing itself because of a job that exceeded the memory limit (which is set to 128M by default).

Running the queue worker with --timeout=600 and --memory=1024 fixed the problem for me.

Marla answered 30/12, 2018 at 0:58 Comment(0)

We have had recurring problems under Linux at a customer site (Red Hat, I think), with OOMKiller (out-of-memory killer) killing both our principle application (i.e. the reason the server exists) and it's data base processes.

In each case OOMKiller simply decided that the processes were using to much resources... the machine wasn't even about to fail for lack of resources. Neither the application nor it's database has problems with memory leaks (or any other resource leak).

I am not a Linux expert, but I rather gathered it's algorithm for deciding when to kill something and what to kill is complex. Also, I was told (I can't speak as to the accuracy of this) that OOMKiller is baked into the Kernel and you can't simply not run it.

Barbican answered 7/4, 2009 at 17:44 Comment(6)

IIRC, OOMKiller is only invoked as a last resort. I think the system will even send a signal to various apps asking them to kindly give up some resources before it is forced to invoke OOMKiller. Take with a grain of salt, as it's been a long time... – Averell 7/4, 2009 at 18:4

You can simply not run it. It is baked into the kernel, but there are options to tune how it runs, and even which processes it is likely to kill. It runs when the whole system is out of memory, not when a specific process is using too much. See my answer for more details. – Findlay 7/4, 2009 at 18:28

Not running oomkiller is pretty easy. echo "2" > /proc/sys/vm/overcommit_memory – Shotton 20/2, 2012 at 0:5

Red Hat doesn't want to allow it to be changed: sudo echo "2" > /proc/sys/vm/overcommit_memory /proc/sys/vm/overcommit_memory: Permission denied – Rianna 31/7, 2014 at 21:46

Try echo 2 | sudo tee /proc/sys/vm/overcommit_memory – Hakan 12/2, 2015 at 20:8

@Hakan should be noted to pay attention to running this command when your server is on high load. Or, at least, it gave me some troubles (disconnection from ssh, and killing all the processes) – Alainealair 11/11, 2023 at 8:2

The user has the ability to kill his own programs, using kill or Control+C, but I get the impression that's not what happened, and that the user complained to you.

root has the ability to kill programs of course, but if someone has root on your machine and is killing stuff you have bigger problems.

If you are not the sysadmin, the sysadmin may have set up quotas on CPU, RAM, ort disk usage and auto-kills processes that exceed them.

Other than those guesses, I'm not sure without more info about the program.

Retrenchment answered 7/4, 2009 at 17:12 Comment(1)

CTRL-C sends a different kill than the OP reported (SIGINT (2) as I recall, whereas the program is receiving a SIGKILL (9)). – Desimone 7/4, 2009 at 17:26

I encountered this problem lately. Finally, I found my processes were killed just after Opensuse zypper update was called automatically. To disable zypper update solved my problem.

Logician answered 29/10, 2012 at 5:55 Comment(1)

I am seeing the same issue. How did u track down which process killed your process? Seems there is a tool to check who sends SIGKILL to a process. – Stigma 4/10, 2014 at 18:59

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Let me first explain when and why OOMKiller get invoked?

Where can I find logs of OOMKiller?

Some typical solutions:

Recommended topics

Hot tags