DDOS攻撃を受けた後、どういうわけか/proc/kcore
は非常に大きいため、小さなphpクラスを使用して現在のディスク容量と使用されている数を確認します。
以下が表示されます。
Total Disk Space: 39.2 GB
Used Disk Space: 98 GB
Free Disk Space: 811.6 MB
私の質問は、/proc/kcore
ファイルを削除しても安全ですか?または、通常のサイズに戻す方法があります。
/proc/kcore
のファイルサイズは140.737.486.266.368バイトです
DigitalOceanでサーバーをホストしました。
さらに情報が必要な場合は、お問い合わせください;)
どうもありがとう!
編集...
df -h
は以下を返します。
Filesystem Size Used Avail Use% Mounted on
/dev/vda 40G 37G 755M 99% /
udev 993M 12K 993M 1% /dev
tmpfs 401M 224K 401M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1002M 0 1002M 0% /run/shm
du -shx
は以下を返します。
du -shx *
8.7M bin
27M boot
12K dev
6.3M etc
4.8M home
0 initrd.img
229M lib
4.0K lib64
16K lost+found
8.0K media
4.0K mnt
4.0K opt
du: cannot access `proc/3765/task/3765/fd/3': No such file or directory
du: cannot access `proc/3765/task/3765/fdinfo/3': No such file or directory
du: cannot access `proc/3765/fd/3': No such file or directory
du: cannot access `proc/3765/fdinfo/3': No such file or directory
0 proc
40K root
224K run
8.0M sbin
4.0K selinux
4.0K srv
0 sys
4.0K tmp
608M usr
506M var
0 vmlinuz
lsof | grep deleted
の結果:
mysqld 1356 mysql 4u REG 253,0 0 1835011 /tmp/ib4jBFkc (deleted)
mysqld 1356 mysql 5u REG 253,0 0 1835012 /tmp/ibcE99rr (deleted)
mysqld 1356 mysql 6u REG 253,0 0 1835013 /tmp/ibrxYEzG (deleted)
mysqld 1356 mysql 7u REG 253,0 0 1835014 /tmp/ibK95UJV (deleted)
mysqld 1356 mysql 11u REG 253,0 0 1835015 /tmp/iboOi8Ua (deleted)
nginx 30057 root 2w REG 253,0 0 789548 /var/log/nginx/error.log (deleted)
nginx 30057 root 5w REG 253,0 37730323404 268273 /etc/nginx/off (deleted)
nginx 30057 root 6w REG 253,0 0 789548 /var/log/nginx/error.log (deleted)
nginx 30058 www-data 2w REG 253,0 0 789548 /var/log/nginx/error.log (deleted)
nginx 30058 www-data 5w REG 253,0 37730323404 268273 /etc/nginx/off (deleted)
nginx 30058 www-data 6w REG 253,0 0 789548 /var/log/nginx/error.log (deleted)
nginx 30059 www-data 2w REG 253,0 0 789548 /var/log/nginx/error.log (deleted)
nginx 30059 www-data 5w REG 253,0 37730323404 268273 /etc/nginx/off (deleted)
nginx 30059 www-data 6w REG 253,0 0 789548 /var/log/nginx/error.log (deleted)
元の質問への回答:
「_
/proc/kcore
_ファイルを削除しても保存されますか?または、通常のサイズに戻す方法があります。」
いいえ、安全ではありません。まあ、とにかくそれを削除したらどうなるのか賭けたくありません!
_/proc
_ディレクトリはprocfsのマウントポイントです(mount
を実行すると、以下のような出力が表示されます:)
_proc on /proc type proc (rw)
_
procfsはちょっとした魔法です。その中のファイルは本物ではありません。ファイルシステムのように見え、ファイルシステムのように機能し、ファイルシステムです。ただし、ディスク(または他の場所)に保存されているものではありません。
_/proc/kcore
_は、具体的には、仮想メモリで使用可能なすべてのバイトに直接マップされるファイルです...詳細については絶対に明確ではありません。 128TBは、Linuxが仮想メモリに利用可能な64ビットのうち47ビットを割り当てたことに由来します。
(128TBの制限に関する議論はここにあります: https://unix.stackexchange.com/questions/116640/what-is-maximum-ram-supportable-by-linux )
とにかく、Linuxのハードコードされた仮想メモリの制限は別として、質問の文脈で理解できるようになったのは次のとおりです。_/proc/kcore
_は、仮想procfsファイルシステムによって提供されるシステムファイルであり、実際のファイルではありません。
削除しないでください;-)
更新:2016-06-03
ここでの私の答えは定期的にアップ投票されます-だから、人々はまだ_/proc/kcore
_とは何かの説明を探していると思います。
Everything is a file というタイトルのウィキペディアの役立つ記事があります。本当に興味があるなら、Plan9 OSを見てください。
私の元の答えがkcore
自体を十分に説明していることを願っています。この答えを読んでいる人は_/proc
_の他のファイルにも興味があるのではないかと推測しています。他の「興味深い」例もいくつかあります。
_/proc/sys/*
_は、ユーザー(あなた)がLinuxの中心(カーネルと関連ドライバーなど)から詳細を読み書きするためのメカニズムです。 r/wアイテムのかわいい例は、「 IP転送 」です。
読み取り:_cat /proc/sys/net/ipv4/ip_forward
_(_0
_はオフ、_1
_はオン)
書き込み:_echo 1 > /proc/sys/net/ipv4/ip_forward
_
kcore
と同様に、これは実際のファイルではありません。しかし、それは1つのように機能します。したがって、書き込みを行うと、実際にはディスク上のバイトではなくソフトウェア設定を変更していることになります。
_/proc/meminfo
_および_/proc/cpuinfo
_は読み取り専用です。 cat
またはless
それら、またはfopen()
を独自のアプリケーションから作成できます。ハードウェア(メモリとCPU)に関する詳細が表示されます。
_/proc/[0-9]+
_は実際にはプロセスIDがマシンで実行されています!これらは(_IMHO)_/proc
_の最もクールな機能です。それらの内部には、プロセスを開始するために使用されたコマンドを示すcmdline
などの偽のファイルがあります。
最後に、_/proc
_のような「興味深いファイルシステム」の他の例があります。 purely in-memory と "user-space" があります。繰り返しますが、これらの(一般的に言えば)本当のディスク領域を消費しませんが、df
やls
のようなツールは実際のファイルサイズを報告します。
コマンドSudo rm /proc/kcore
を実行することは完全に安全です。 rm: cannot remove '/proc/kcore': Operation not permitted
と言うだけです。
/proc
内のすべてのファイルは実際にはハードドライブ上に存在しないため、削除できません。これらのファイルは、システムに関する情報を表します。たとえば、ls /proc
を実行すると、システム上のプロセスのリストをカーネルに要求します。 ls -l /proc/22/exe
を実行する場合、プロセス番号22の実行可能ファイルのファイルパスをカーネルに要求しています。
削除されたが予約されているファイルのディスクをクリーンアップする必要があるようです。次のような「tune2fs」コマンドを使用できます。
tune2fs -m 1 /dev/<drive>
これにより、予約済みブロックスペースが解放され、特権プロセスの予約済みディスクスペースにアクセスできるようになります。 1は後で特権プロセスに割り当てられる割合であることに注意してください。syslogやsshなどの重要なプロセスに十分なディスク容量がある場合にのみ、これを行ってください。
注: '/ proc'からファイルを削除しても、ディスク容量が増えることはありません。これは、HDDのスペースとは何の関係もない仮想ファイルシステムです。
ログファイルの容量を確認してください。すべてのエラーログとアクセスログファイルを削除し、Webサイトを実行しています。
このコマンドを使用すると、どのフォルダーがより多くのスペースを必要とします。
cd /
Sudo du -sh * 2>/dev/null | sort -h