logo标签列表

/proc kcore文件巨大

proc
64

在经历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)
1
/proc 应该是一个虚拟文件系统，如果你在那里删除了某些内容，你不应该得到任何实际的磁盘空间... 运行 df -h 命令查看实际已使用的磁盘空间。 - Wrikken
@Wrikken 我已经更新了帖子，还剩755 MB。 - Love2Code
是的，看起来像是个问题，但删除proc中的某些内容并不能解决它（查看mount的输出，它只是procfs）。它也比你声称在kcore中拥有的127TB要小得多。似乎还需要进行一些清理工作，但不是在/proc目录下。我通常从根目录开始使用du -shx *逐步深入大目录，查看哪些目录很大，然后再用另一个du -shx *进一步查找真正的源头。顺便说一句：在DDOS之后，运行logrotate -f /etc/logrotate.conf将日志轮换，以防止其被填满无意义的东西。 - Wrikken
4
好的，这意味着有很多已经被删除的文件仍然没有被从文件系统中清除，因为某些进程仍然在使用它们（它们的inode仍然存在/尚未释放）。你能否查看一下 lsof | grep deleted？它会告诉你哪些已删除的文件仍然存在，以及哪个进程ID仍然与之有关。通常情况下，停止或重启该进程将清理这些inode。 - Wrikken
3
我知道这个方法有点老了，但解决 /proc/kcore 文件过大的一种方法是重新启动计算机，这会立即将文件大小降至更小的级别。 - Raptor
显示剩余8条评论
4个回答
93
作为对您最初问题的回答：
“删除/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的解释。

有一篇有用的维基百科文章标题为一切皆文件，可以提供一些背景知识。如果你真的很好奇，请看一下Plan9操作系统。

希望我的原始答案已经足够解释了kcore本身。 我推测阅读这个答案的人可能也对/proc中的其他文件感到好奇 - 因此这里有一些其他“有趣”的例子。

  • /proc/sys/* 是一个机制，让用户（您）可以读/写来自 Linux 核心（内核和相关驱动程序等）的详细信息。一个可爱的读/写项目示例是 "IP forwarding":

    读取： cat /proc/sys/net/ipv4/ip_forward（0 表示关闭，1 表示开启）

    写入： echo 1 > /proc/sys/net/ipv4/ip_forward

    与 kcore 一样，这不是一个真正的文件。但它的作用就像一个文件。因此，当您写入它时，实际上是更改软件设置，而不是磁盘上的字节。

  • /proc/meminfo 和 /proc/cpuinfo 是只读的。您可以使用 cat 或 less 命令查看它们，或从您自己的应用程序中使用 fopen() 打开它们。它们显示有关您的硬件（内存和 CPU）的详细信息。

  • /proc/[0-9]+ 实际上是在您的计算机上运行的进程 ID！这些（在我看来）是 /proc 最酷的功能。在其中，您将找到更多的虚假文件，如 cmdline，它们会告诉您启动进程时使用了什么命令。

最后还有一些其他的“有趣文件系统”的例子，比如/proc。这里只举两个例子，一个是纯内存，另一个是用户空间。同样地，这些文件系统（一般来说）不会占用任何真实的磁盘空间，尽管像df和ls这样的工具可能会报告真实的文件大小。

4
无法删除/proc/kcore，如果尝试删除会显示“操作不允许”。 - tbodt
@tbodt 我从来没有尝试过！谢谢你提供的额外信息。 - wally
在/proc中的其他所有内容也是如此。 - tbodt
2
Sophos免费病毒扫描器卡在这个文件上了。看起来它真的在扫描128 TB :) 解决方法：将-exclude /proc/kcore添加到savscan命令行的末尾。 - Roel Van de Paar
9
运行命令sudo rm /proc/kcore是完全安全的。它只会显示rm：无法删除'/proc/kcore'：操作不允许。 /proc目录下的所有文件实际上并不存在于硬盘中，因此它们无法被删除。这些文件代表了关于系统的信息。例如，当您运行ls /proc时，您正在向内核请求获取系统上进程的列表。如果您运行ls -l /proc/22/exe，您正在向内核请求获取进程号为22的可执行文件路径。等等。
3
请检查您的日志文件空间。我删除了所有错误日志和访问日志文件，现在我的网站正在运行。
使用以下命令来检查哪个文件夹占用了更多的空间：
cd /
sudo du -sh * 2>/dev/null | sort -h
0

看起来你需要清理掉已删除但被保留的文件。你可以使用'tune2fs'命令，例如：

tune2fs -m 1 /dev/<drive>

这将释放保留的块空间并使您可以访问特权进程保留的磁盘空间。请注意，1是之后分配给特权进程的百分比，仅在您有足够的磁盘空间用于诸如syslog或ssh等关键进程时才执行此操作。

注意：从“/proc”中删除文件永远不会获得磁盘空间。那是一个虚拟文件系统，与您硬盘驱动器上的空间毫无关系。

1
关于/proc的解释是正确的。我不熟悉tune2fs；有人可以解释一下它是做什么的（如果有什么问题，那是什么）吗？ - Tom
我可以告诉你，我发布这个答案的原因是因为它解决了和你遇到的同样的问题。不确定为什么会被踩，但如果它解决了你的问题那就太好了...既然踩票没有给出理由，也许你可以确认一下这个答案是否有用。 - Atari911
我不是原帖作者，也没有遇到同样的问题，只是偶然来到这里，所以我无法加强答案 - 我只能说它对我来说似乎是合理的，并且如果投票者留下了评论，那将是很好的。除此之外，我只是好奇tune2fs是做什么的。 - Tom
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接