linux 何が私のプロセスを殺したの?




systemd screen (10)

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

最近、ユーザーはしばらくの間アプリケーションを実行していて、それは不思議に亡くなりました。 テキスト:

殺された

ターミナルにありました。 これは2回起こった。 私は、別のターミナルの誰かがkillコマンドを使ってプロセスを終了させるかどうか尋ねました。 いいえ。

Linuxはどのような条件の下で私のプロセスを殺すのだろうか? kill(9)シグナルを受け取った後にプロセスが終了したため、シェルは "kill"と表示されたと思います。 Linuxがkillシグナルを送信した場合、なぜシステムログにどこの場所にメッセージがあり、それがなぜ殺されたのかがわかるはずです。


ユーザーはkillやControl + Cを使用して自分のプログラムを殺す能力を持っていますが、私は何が起こったのか、そしてユーザーがあなたに苦情を言ったという印象を受けます。

rootにはもちろんプログラムを強制終了させる能力がありますが、もしあなたのマシンにroot権限を持ち、物事を殺しているならあなたはもっと大きな問題を抱えています。

sysadminでない場合、sysadminはCPU、RAM、またはディスクの使用量にクォータを設定し、それらを超えるプロセスを自動殺します。

これらの推測以外に、私はプログラムについての情報がないとわからない。


試してください:

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

-B100は、 -B100が発生する前の行数を示します。

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


これは、件名の良い記事のように見えます。

要点は、Linuxがメモリを誇張しているということです。 プロセスがより多くのスペースを要求すると、Linuxは他のプロセスによって要求されたとしても、誰も実際に要求するすべてのメモリを実際に使用していないという前提で、そのスペースを与えます。 プロセスは、要求したときではなく、実際に使用したときに割り当てたメモリを排他的に使用します。 これにより、割り当てが迅速になり、実際よりも多くのメモリを割り当てることができます。 しかし、プロセスがこのメモリの使用を開始すると、Linuxはそれが持っていないメモリを割り当てることにはあまりにも寛大で、一部を解放するためにプロセスを停止する必要があることを認識するかもしれません。 プロセスは、ランタイム(長期実行プロセスがより安全)、メモリ使用量(貪欲プロセスは安全性が低い)、およびプロセスを少なくするために調整できる値など、いくつかの要因を考慮したスコアに基づいています殺される可能性が高い。 この記事で詳しく説明しています。

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


まず、OOMKillerがいつ呼び出されるのか、またなぜOOMKillerが呼び出されるのかを説明しましょう。

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

今、いくつかの時間はすべて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. ログとGoogleを参照してください:)

これは、Linux out of memory manager(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

lsf環境(インタラクティブまたはそれ以外の場合)で、アプリケーションがキューの管理者またはキューへのサブミットによってあらかじめ設定されたしきい値を超えてメモリ使用率を超えた場合、プロセスは強制終了され、他のユーザーは潜在的な犠牲者にならない逃げる。 セットアップの方法によっては、メールが送信されるとは限りません。

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

あなたはman ulimitを見直したいかもしれません

私はそれを必要として以来、 Killedれたulimit覚えていませんが、しばらくしています。


リソースを制限するPAMモジュールは、あなたが記述した結果を正確に引き起こしました。私のプロセスは、コンソールウィンドウでKilledというテキストで間違って死んでしまいました。 syslogkern.logもログ出力がありません。 topプログラムは、CPU使用量が1分後にプロセスが強制終了されたことを正確に発見するのに役立ちました。


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


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_ubacktrace()それぞれ、カーネルとユーザスペースについては、 print_backtrace()および/またはprint_ubacktrace()をプローブに追加します)。


ユーザまたはsysadminがカーネルが持つプログラムを強制終了しなかった場合。 カーネルは、極端なリソースの飢餓(mem + swapの枯渇と思われる)のような例外的な状況下でプロセスを殺すだけです。







signals