无法删除或列出目录 (ls 或 rm) Linux - Debian

Question 1

在我看来，目录中可能有大量文件。我在非常大的目录中看到了与您描述的非常相似的症状。

可能存在某种问题（可能是 logrotate 的配置问题），导致您最终拥有数百万个文件。一旦达到数百万个文件，大多数文件系统都会开始出现问题。仅仅执行一个操作ls就需要花费大量时间，如果您等待的时间足够长，甚至可能会死机。rm由于文件数量庞大，类似命令也会出现问题。同样，像 logrotate 这样的命令似乎会挂起，因为对目录执行简单的操作需要很长时间才能完成。

验证这一点的一种方法是执行ls -l上述目录（本例中为 /var/log/apache2/）并查看目录条目的大小（而不是内容）。例如（从我的服务器，其中有几个目录，其中包含许多文件）：

$ ls -lh
rwxrwxr-x 2 ironport ironport  11M Apr 21 19:37 oma01syslog01/
drwxrwxr-x 2 ironport ironport  12M Apr 21 19:37 oma01syslog02/
drwxrwxr-x 2 ironport ironport 5.8M Mar 17 12:30 sat01syslog01/
drwxrwxr-x 2 ironport ironport 4.0K Jun 29  2011 swn01syslog01/

$ for DIR in * ; do echo -n "$DIR:  " ; find $DIR -type f -print | wc -l ; done
oma01syslog01:  204332
oma01syslog02:  195500
sat01syslog01:  70960
swn01syslog01:  0

注意目录条目的大小与其中的文件数量相比。

最好的办法是尝试使用类似的命令来查看文件find。它不会在显示文件之前尝试拉取整个列表，并且可以让你查询和操作目录，而不会出现和中出现的问题ls。rm下面是一些有用的例子。

文件数量：

find ./directory/name/here -type f -print | wc -l

查看目录中的文件示例：

find ./directory/name/here -type f -print | head -20 | xargs ls -lh

从目录中删除所有匹配模式的文件：

find ./directory/name/here -type f -iname '*.log' -print | xargs rm -rf

笔记：我刚刚注意到您的评论，其中您展示了ls从一个目录向上的内容：

drwxr-xr-x 2 root root 126406656 2011-10-17 18:51 vhosts

这证实了我的怀疑。126406656 字节等于 120MB。这是一个非常大的目录条目（从我上面的示例来看，我有一个 11MB 的目录条目，里面有 200k 个文件），这表明该目录中有数百万个文件。

Answer

在我看来，目录中可能有大量文件。我在非常大的目录中看到了与您描述的非常相似的症状。

可能存在某种问题（可能是 logrotate 的配置问题），导致您最终拥有数百万个文件。一旦达到数百万个文件，大多数文件系统都会开始出现问题。仅仅执行一个操作ls就需要花费大量时间，如果您等待的时间足够长，甚至可能会死机。rm由于文件数量庞大，类似命令也会出现问题。同样，像 logrotate 这样的命令似乎会挂起，因为对目录执行简单的操作需要很长时间才能完成。

验证这一点的一种方法是执行ls -l上述目录（本例中为 /var/log/apache2/）并查看目录条目的大小（而不是内容）。例如（从我的服务器，其中有几个目录，其中包含许多文件）：

$ ls -lh
rwxrwxr-x 2 ironport ironport  11M Apr 21 19:37 oma01syslog01/
drwxrwxr-x 2 ironport ironport  12M Apr 21 19:37 oma01syslog02/
drwxrwxr-x 2 ironport ironport 5.8M Mar 17 12:30 sat01syslog01/
drwxrwxr-x 2 ironport ironport 4.0K Jun 29  2011 swn01syslog01/

$ for DIR in * ; do echo -n "$DIR:  " ; find $DIR -type f -print | wc -l ; done
oma01syslog01:  204332
oma01syslog02:  195500
sat01syslog01:  70960
swn01syslog01:  0

注意目录条目的大小与其中的文件数量相比。

最好的办法是尝试使用类似的命令来查看文件find。它不会在显示文件之前尝试拉取整个列表，并且可以让你查询和操作目录，而不会出现和中出现的问题ls。rm下面是一些有用的例子。

文件数量：

find ./directory/name/here -type f -print | wc -l

查看目录中的文件示例：

find ./directory/name/here -type f -print | head -20 | xargs ls -lh

从目录中删除所有匹配模式的文件：

find ./directory/name/here -type f -iname '*.log' -print | xargs rm -rf

笔记：我刚刚注意到您的评论，其中您展示了ls从一个目录向上的内容：

drwxr-xr-x 2 root root 126406656 2011-10-17 18:51 vhosts

这证实了我的怀疑。126406656 字节等于 120MB。这是一个非常大的目录条目（从我上面的示例来看，我有一个 11MB 的目录条目，里面有 200k 个文件），这表明该目录中有数百万个文件。

Question 2

这应该服务器故障，但：

您的目录中的读取位似乎关闭：使用类似chmod a+r目录名来改正它。

这很可能发生在创建目录时；日志轮换脚本会这样做吗？完全可以预料到，此脚本的多个并发实例会导致问题，但我很惊讶它会在目录上产生权限问题。无论如何，您需要一种更快的轮换方式，并且可能需要一种机制来阻止脚本在已经运行时启动。

Answer

这应该服务器故障，但：

您的目录中的读取位似乎关闭：使用类似chmod a+r目录名来改正它。

这很可能发生在创建目录时；日志轮换脚本会这样做吗？完全可以预料到，此脚本的多个并发实例会导致问题，但我很惊讶它会在目录上产生权限问题。无论如何，您需要一种更快的轮换方式，并且可能需要一种机制来阻止脚本在已经运行时启动。

Question 3

挂起任务是一种非常严重的错误。它非常严重，因此有一个名为 /proc/sys/kernel/hung_task_panic 的 proc 文件可以自动导致崩溃/重启。这意味着某个进程在内核中挂起很长时间，正常使用情况下不应该发生这种情况。

检查你的内存使用情况/交换
检查你的文件系统/磁盘

Answer

挂起任务是一种非常严重的错误。它非常严重，因此有一个名为 /proc/sys/kernel/hung_task_panic 的 proc 文件可以自动导致崩溃/重启。这意味着某个进程在内核中挂起很长时间，正常使用情况下不应该发生这种情况。

检查你的内存使用情况/交换
检查你的文件系统/磁盘

Question 4

问题似乎已经解决了？！？！

我注意到服务器的负载已经从峰值平均约 70 下降到徘徊在 1-3 左右（正常水平）。

我运行：screen rm -rf vhosts

大约半小时后回来并尝试恢复屏幕，但什么也没发生。耶！目录已被删除。

确实不知道发生了什么/正在发生什么，但至少部分问题已经消失。

不再有奇怪的内核错误。

Answer