何が私のプロセスを殺しましたか、そしてなぜですか？

私のアプリケーションはLinuxのバックグラウンドプロセスとして実行されます。現在、ターミナルウィンドウのコマンドラインから開始されます。

最近、ユーザーがしばらくアプリケーションを実行していて、不思議なことに死にました。テキスト：

殺された

ターミナルにいた。これは2回起こりました。別のターミナルの誰かがkillコマンドを使用してプロセスを強制終了したかどうかを尋ねました。番号。

Linuxはどのような状況下でプロセスを強制終了することを決めますか？kill（9）シグナルを受信した後にプロセスが停止したため、シェルが「killed」を表示したと思います。Linuxがkillシグナルを送信した場合、システムログのどこかに、それがkillされた理由を説明するメッセージがありますか？

ユーザーまたはsysadminがプログラムを強制終了しなかった場合、カーネルが持っている可能性があります。カーネルは、極端なリソース不足（mem + swapの枯渇など）などの例外的な状況でのみプロセスを強制終了します。

試してください：

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

ここで-B100、キルが発生する前の行数を示します。

Mac OSでは-Tを省略します。

これは主題に関する良い記事のように見えます：OOMキラーを飼いならすこと。

要点は、Linuxがオーバーコミットすることですメモリ。プロセスがより多くのスペースを要求すると、Linuxは、そのスペースを他のプロセスから要求されたとしても、要求したすべてのメモリを実際に使用する人はいないという前提の下で、そのスペースを割り当てます。プロセスは、要求したときではなく、実際に使用するときに割り当てたメモリを排他的に使用します。これにより、割り当てが迅速になり、実際に持っているよりも多くのメモリを「チート」して割り当てることができる場合があります。ただし、プロセスがこのメモリの使用を開始すると、Linuxは、メモリが割り当てられていないため、プロセスを強制終了して解放する必要があることに気付く場合があります。強制終了されるプロセスは、ランタイム（長期実行プロセスの方が安全です）、メモリ使用量（貪欲プロセスは安全性が低い）、およびその他のいくつかの要因を考慮したスコアに基づいています。プロセスが強制終了される可能性を低くするために調整できる値を含めます。それはすべて、記事でより詳細に説明されています。

編集：そして、これはプロセスがどのように選択されるかをかなりよく説明する別の記事です（いくつかのカーネルコード例で注釈が付けられています）。これの素晴らしい点は、さまざまなルールの背後にある推論についてのいくつかの解説が含まれていることbadness()です。

最初に、OOMKillerが呼び出されるタイミングと理由を説明しましょう。

512 RAM + 1 GBスワップメモリ​​があるとします。したがって、理論的には、CPUは合計1.5 GBの仮想メモリにアクセスできます。

しばらくの間、すべてのメモリが1.5GB以内で問題なく動作しています。しかし、突然（または徐々に）システムがますます多くのメモリを消費し始め、使用された合計メモリの約95％の時点に達しました。

ここで、任意のプロセスがカーネルに大量のメモリを要求したとしましょう。カーネルが使用可能なメモリをチェックし、プロセスにメモリを割り当てる方法がないことを確認します。したがって、メモリの呼び出し/ OOMKiller（http://linux-mm.org/OOM）の呼び出しを解放しようとします。

OOMKillerには、すべてのプロセスのランクをスコアリングする独自のアルゴリズムがあります。通常、どのプロセスがより多くのメモリを使用するかが、強制終了の犠牲になります。

OOMKillerのログはどこにありますか？

通常は/ var / logディレクトリにあります。/var/log/kern.logまたは/ var / log / dmesgのいずれか

これがお役に立てば幸いです。

いくつかの典型的な解決策：

1. メモリを増やす（スワップではない）
2. プログラムのメモリリークを見つけて修正する
3. プロセスが消費できるメモリを制限します（たとえば、JAVA_OPTSを使用してJVMメモリを制限できます）
4. ログとグーグルを参照してください:)

これは、Linux のメモリ不足マネージャ（OOM）です。あなたのプロセスが原因「に選ばれた悪新しさの組み合わせ、（ちょうど割り当てられたのではなく、使用中のメモリ、）常駐サイズおよびその他の要因- 」。

sudo journalctl -xb

次のようなメッセージが表示されます。

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

dwcとAdam Jaskiewiczが述べたように、犯人はおそらくOOM Killerです。ただし、次の質問は次のとおりです。これを防ぐにはどうすればよいですか？

いくつかの方法があります。

1. 可能な場合はシステムにRAMを追加します（VMの場合は簡単です）。
2. OOMキラーが別のプロセスを選択していることを確認してください。
3. OOMキラーを無効にする
4. OOM Killerを無効にした状態で出荷されるLinuxディストリビューションを選択します。

この記事のおかげで、（2）は実装が特に簡単であることがわかりました。

リミット・リソースへのPAMモジュールあなたが説明した正確な結果原因は：私のプロセスは、テキストと不思議に死亡した殺したコンソールウィンドウに。ログは出力されず、syslogにもkern.logにも出力されません。一番上のプログラムは、CPUを1分間使用した直後にプロセスが終了することを発見するのに役立ちました。

systemtap（またはトレーサー）のようなツールは、カーネルの信号伝送ロジックを監視し、報告することができます。例：https://sourceware.org/systemtap/examples/process/sigmon.stp

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

このifスクリプトのフィルタリングブロックは、好みに合わせて調整したり、システム全体の信号トラフィックを追跡するために削除したりできます。原因は、さらに（追加バックトレースを収集することにより単離することができるprint_backtrace()及び/又はprint_ubacktrace()kernel-ため、プローブにそれぞれuserspace-）。

lsf環境（インタラクティブまたはその他）で、アプリケーションがキューの管理者によって事前に設定されたしきい値を超えてメモリ使用率を超えた場合、またはキューへの送信でリソース要求が発生した場合、他のユーザーが潜在的な犠牲にならないようにプロセスが強制終了されます逃げる。設定によっては、送信時にメールが送信されるとは限りません。

この場合の1つの解決策は、より大きなリソースを持つキューを見つけるか、送信でより大きなリソース要件を定義することです。

また、レビューすることもできます man ulimit

私は覚えていないが、ulimit結果としてKilled、私はそれを必要とするので、そのなっている間。

Linuxの顧客サイト（Red Hatだと思います）で繰り返し問題が発生しました。OOMKiller（メモリ不足のキラー）により、主要なアプリケーション（つまり、サーバーが存在する理由）とデータベースプロセスの両方が停止します。

どちらの場合も、OOMKillerはプロセスが多くのリソースを使用していると単純に判断しました...リソースの不足のためにマシンが故障することすらありませんでした。アプリケーションにもデータベースにも、メモリリーク（またはその他のリソースリーク）の問題はありません。

私はLinuxのエキスパートではありませんが、何かをいつ殺すか、何を殺すかが複雑であるかを判断するためのアルゴリズムを集めました。また、OOMKillerはカーネルに組み込まれているので、実行できないと言われました（これの正確さについては言えません）。

私の場合、これはLaravelキューワーカーで発生していました。システムログには殺害についての記述がないため、さらに調べたところ、ジョブはメモリ制限（デフォルトでは128Mに設定されています）を超えているため、ワーカーが基本的に殺害していることがわかりました。

キューワーカーを実行--timeout=600し、--memory=1024私のために問題を修正しました。

ユーザーはkillまたはControl + Cを使用して自分のプログラムを強制終了することができますが、私は何が起こったのかではなく、ユーザーが不平を言っているように感じます。

もちろん、rootはプログラムをkillする能力を持っていますが、誰かがあなたのマシンにrootを持ち、何かをkillしている場合、あなたはより大きな問題を抱えています。

システム管理者でない場合は、システム管理者がCPU、RAM、またはディスク使用量に割り当てを設定し、それらを超えるauto-killsプロセスを行っている可能性があります。

これらの推測以外には、プログラムについての詳細な情報がないとわかりません。

最近この問題に遭遇しました。最後に、Opensuse zypperアップデートが自動的に呼び出された直後にプロセスが強制終了されたことがわかりました。zypper更新を無効にすることで問題が解決しました。

スワップサイズを増やすことでこの問題を解決しました：

/ubuntu/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04