/proc/kcoreという巨大ファイルの削除方法

Question

前提・実現したいこと

本番環境の物理サーバにssh接続時に、「/proc/kcore」の128TBのファイルが作成され、ディスク使用率が99%となっている。

発生している問題・エラーメッセージ

エラーメッセージ
/var/log/messagesにはエラーは表示されていない。

cronで動作しているアップデート系や、動作ログ量次第でリモートログインも不可となる可能性あり。

試したこと

本番稼働サーバのため、不要ファイルでのディスクサイズ確保と、参照系のコマンドしか実施ができない状況。（OSリブートは未実施）
また、proc領域に対してのrm系はエラーとなることは認知しており、本サイトやWebサイトでの検索結果から情報を収集
以前、同様の事象を解消した記憶があるが、失念してしまっております。

以上、対処法についてご存じの方がおりましたら、ご教授よろしくお願いいたします。

Comments

[int32_t]

/proc/kcore が何なのか調べましたか?

[hoshi-takanori]

これかな。
https://stackoverflow.com/questions/21170795/proc-kcore-file-is-huge
(あやしげな日本語訳があります。)
https://codehero.jp/proc/21170795/proc-kcore-file-is-huge

Answer 1

そのファイルは仮想的なものであって物理的にディスクを消費しているわけではありません。

ハウツー：/procディレクトリを活用する | OSDN Magazine

なお他の仮想ファイルとは違って/proc/kcoreはRAMと同じ容量（とわずかなオーバーヘッド分の容量）の大きさがあるように表示される

Comments

[naizawa]

ありがとうございます、参考にさせていただきました。

Answer 2

回答のある通りですが、/proc/kcoreや/dev/coreは、仮想メモリ空間全体をファイルとしてアクセスするための仮想ファイルです。
サイズが128TBなのは、現在のカーネルの設定で扱える仮想メモリ空間のサイズが128TB(2の47乗)ということです。

ディスクの使用量調査は何らかの便利ツールが探せばあると思いますが、
基本的には、du /の結果をExcelなどで分析してディレクトリを絞り込むのでしょうか。
結果は膨大なので、du --max-depth=3 /とかで上から数階層に絞ったりした方が良いかもしれません。

これで見つからないとすると、ファイル名を持ってないファイル（プロセスが掴んでいる名無しファイル）の可能性もあります。

Comments

[naizawa]

回答ありがとうございます。128TB(2の47乗)理解できました。
これまで皆様から頂いている回答を基に調査を進めていきたいと思います。

[naizawa]

あれから色々とサーバ内を調べファイルメンテナンスを実施ましたが、稼働に必要なリソースを確保する事ができたため、サーバ再起動が可能なタイミングまで様子見とさせていただく事となりました。
ご回答いただいた皆様に感謝するとともに、こちらをベストアンサーとさせていただきます。本当にありがとうございました。

Answer 3

とりあえず /proc/kcore が原因ではなさそうですね。

このファイルは、システムの物理メモリを示し、コアファイル形式で保管されます。大半の /proc/ ファイルとは異なり、kcore ではサイズが表示されます。この値はバイト単位で示され、使用中の物理メモリ (RAM) の容量に 4 KB を加算した値となります。
E.2.13. /proc/kcore Red Hat Enterprise Linux 6 | Red Hat Customer Portal

Comments

[naizawa]

参照リンク参考になりました。kcore自体深くは知らなかったものでしたので。ありがとうございます。

Answer 4

ウチのVirtualBox上の仮想マシンでも巨大なファイルサイズなように表示されましたが、実際のディスク容量には影響ありませんでした。

[root@localhost ~]#
[root@localhost ~]# ls -l /proc/kcore
-r--------. 1 root root 140737477885952  8月 23 16:22 /proc/kcore
[root@localhost ~]#
[root@localhost ~]# df -hT
ファイルシス               タイプ   サイズ  使用  残り 使用% マウント位置
devtmpfs                   devtmpfs   386M     0  386M    0% /dev
tmpfs                      tmpfs      405M     0  405M    0% /dev/shm
tmpfs                      tmpfs      405M  5.5M  400M    2% /run
tmpfs                      tmpfs      405M     0  405M    0% /sys/fs/cgroup
/dev/mapper/almalinux-root xfs         47G  1.7G   46G    4% /
/dev/sda1                  xfs       1014M  197M  818M   20% /boot
tmpfs                      tmpfs       81M     0   81M    0% /run/user/0
[root@localhost ~]#
[root@localhost ~]#

ディスク使用率が99%であるのは別の要因ではないでしょうか。(本当にディスクを圧迫しているファイルが存在しているはず。)

duコマンドで地道に探していくしかないと思います。

Comments

[naizawa]

回答ありがとうございます。duで調べてみます。ちなみにdf結果となります。
多少ファイル削除してます。
# df -hT
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 16G 0 16G 0% /dev
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 16G 90M 16G 1% /run
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/md126 50G 47G 3.4G 94% /
/dev/md123 50G 8.8G 42G 18% /var
/dev/md125 1020M 233M 788M 23% /boot
/dev/md124 201M 12M 190M 6% /boot/efi
tmpfs 3.2G 0 3.2G 0% /run/user/1000

Answer 5

「/proc/kcore」の128TBのファイルが作成され、ディスク使用率が99%となっている。

ディスク領域の枯渇は、本当にそのファイルが原因なのでしょうか？

一般的なLinux環境では、/proc以下はprocfsという仮想ファイルシステムであって、実際のディスクは消費しません。

Comments

[naizawa]

回答ありがとうございます。ls結果を忘れておりましたので、追記させていただきます。

# ll /proc/kcore
-r-------- 1 root root 140737486266368 8月 23 13:12 /proc/kcore

[maisumakun]

「mount -l | grep proc」のようにすれば、procが本当にprocfsなのか確認できます。

[naizawa]

確認コマンドありがとうございます。実行結果を記載させて頂きます。

# mount -l | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,
timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15608)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

[maisumakun]

「proc on /proc type proc」とあるとおり、procfsが適用されています。