我在Debian专用服务器上的/ var / log / apache2 / vhosts上有一个日志文件目录。 我每天都将主access_log分割到/ var / log / apache2 / vhosts中的各个vhostname.com_access_log文件中
在上周左右，我已经注意到服务器已经无响应，每次发生这种情况似乎有多个日志旋转实例运行。
经过一番调查，我决定检查/ var / log / apache2 / vhosts的内容来查看是否有某种问题。 我可以'cd'进入目录，但不能列出它的内容。 'ls'命令没有死，只是没有做任何事情。
尝试各种不同的方式列出文件的内容后，我决定删除它，并创build一个新的文件。 在父目录的目录下运行rm似乎并不工作：rm -rf vhosts。 从'top'的angular度来看，我可以看到'rm'正在运行，并使用less量的cpu …现在已经运行了大约一个小时。
任何想法是怎么回事，我怎么能摆脱那个目录？
更多信息：
在/ var / log / messages中看到很多这种types的错误不知道它是否相关：
Oct 15 12:22:39 sp5059b kernel: [2257339.255530] apache2 D a9b86504 0 32217 9125 Oct 15 12:22:39 sp5059b kernel: [2257339.255533] dea15620 00000086 00000000 a9b86504 0007f05b dea157ac c1fdbfc0 00000001 Oct 15 12:22:39 sp5059b kernel: [2257339.255538] 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000 Oct 15 12:22:39 sp5059b kernel: [2257339.255542] f7246ec0 f7246ec8 f7246ec4 dea15620 c02b95c6 c2483e80 d7085e80 dea15620 Oct 15 12:22:39 sp5059b kernel: [2257339.255547] Call Trace: Oct 15 12:22:39 sp5059b kernel: [2257339.255553] [<c02b95c6>] __mutex_lock_slowpath+0x50/0x7b Oct 15 12:22:39 sp5059b kernel: [2257339.255557] [<c02b945c>] mutex_lock+0xa/0xb Oct 15 12:22:39 sp5059b kernel: [2257339.255561] [<c015810c>] generic_file_aio_write+0x41/0xa9 Oct 15 12:22:39 sp5059b kernel: [2257339.255565] [<f892ef99>] ext3_file_write+0x19/0x83 [ext3] Oct 15 12:22:39 sp5059b kernel: [2257339.255575] [<c017460e>] do_sync_write+0xbf/0x100 Oct 15 12:22:39 sp5059b kernel: [2257339.255581] [<c0131a98>] autoremove_wake_function+0x0/0x2d Oct 15 12:22:39 sp5059b kernel: [2257339.255585] [<c0132368>] set_process_cpu_timer+0x27/0xae Oct 15 12:22:39 sp5059b kernel: [2257339.255590] [<c0125be2>] do_setitimer+0x2aa/0x31a Oct 15 12:22:39 sp5059b kernel: [2257339.255594] [<c017e0a0>] fasync_helper+0x3c/0xb7 Oct 15 12:22:39 sp5059b kernel: [2257339.255597] [<c01bafe5>] security_file_permission+0xc/0xd Oct 15 12:22:39 sp5059b kernel: [2257339.255601] [<c017454f>] do_sync_write+0x0/0x100 Oct 15 12:22:39 sp5059b kernel: [2257339.255605] [<c0174d80>] vfs_write+0x83/0x120 Oct 15 12:22:39 sp5059b kernel: [2257339.255608] [<c0175352>] sys_write+0x3c/0x63 Oct 15 12:22:39 sp5059b kernel: [2257339.255612] [<c01038d2>] syscall_call+0x7/0xb Oct 15 12:22:39 sp5059b kernel: [2257339.255618] ======================= 还有一些错误：
Oct 15 12:22:39 sp5059b kernel: [2257339.255618] ======================= Oct 15 13:52:55 sp5059b kernel: [2262820.703285] INFO: task kswapd0:173 blocked for more than 120 seconds. Oct 15 13:52:55 sp5059b kernel: [2262820.703310] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 15 13:52:55 sp5059b kernel: [2262820.703342] kswapd0 D 9527f7ea 0 173 2 Oct 15 13:52:55 sp5059b kernel: [2262820.703346] f747c4e0 00000046 c036f160 9527f7ea 0007f529 f747c66c c1fdbfc0 00000001 Oct 15 13:52:55 sp5059b kernel: [2262820.703352] 00000000 00000001 0051b47e 00000000 00000000 00000000 00000246 c0131ba7 Oct 15 13:52:55 sp5059b kernel: [2262820.703357] f77dc400 f7731dc4 f77dc450 00396fe5 f8899e28 f77dc414 00000000 f747c4e0 Oct 15 13:52:55 sp5059b kernel: [2262820.703362] Call Trace: Oct 15 13:52:55 sp5059b kernel: [2262820.703374] [<c0131ba7>] prepare_to_wait+0x12/0x4d Oct 15 13:52:55 sp5059b kernel: [2262820.703383] [<f8899e28>] log_wait_commit+0x8b/0xd1 [jbd] Oct 15 13:52:55 sp5059b kernel: [2262820.703393] [<c0131a98>] autoremove_wake_function+0x0/0x2d Oct 15 13:52:55 sp5059b kernel: [2262820.703398] [<f88975dd>] journal_try_to_free_buffers+0x123/0x13b [jbd] Oct 15 13:52:55 sp5059b kernel: [2262820.703407] [<f89320f7>] ext3_releasepage+0x0/0x57 [ext3] Oct 15 13:52:55 sp5059b kernel: [2262820.703420] [<c0156409>] try_to_release_page+0x33/0x45 Oct 15 13:52:55 sp5059b kernel: [2262820.703424] [<c015ee80>] shrink_page_list+0x3c7/0x4a8 Oct 15 13:52:55 sp5059b kernel: [2262820.703431] [<c015e349>] isolate_lru_pages+0x44/0x17f Oct 15 13:52:55 sp5059b kernel: [2262820.703436] [<c015e349>] isolate_lru_pages+0x44/0x17f Oct 15 13:52:55 sp5059b kernel: [2262820.703441] [<c015f04f>] shrink_inactive_list+0xee/0x2fd Oct 15 13:52:55 sp5059b kernel: [2262820.703450] [<c015f30e>] shrink_zone+0xb0/0xcd Oct 15 13:52:55 sp5059b kernel: [2262820.703454] [<c015fa64>] kswapd+0x27b/0x3ed Oct 15 13:52:55 sp5059b kernel: [2262820.703459] [<c015e484>] isolate_pages_global+0x0/0x42 Oct 15 13:52:55 sp5059b kernel: [2262820.703463] [<c0131a98>] autoremove_wake_function+0x0/0x2d Oct 15 13:52:55 sp5059b kernel: [2262820.703468] [<c015f7e9>] kswapd+0x0/0x3ed Oct 15 13:52:55 sp5059b kernel: [2262820.703471] [<c01319d7>] kthread+0x38/0x5d Oct 15 13:52:55 sp5059b kernel: [2262820.703474] [<c013199f>] kthread+0x0/0x5d Oct 15 13:52:55 sp5059b kernel: [2262820.703477] [<c01044f7>] kernel_thread_helper+0x7/0x10 Oct 15 13:52:55 sp5059b kernel: [2262820.703482] ======================= Oct 17 16:39:21 sp5059b kernel: [2448749.835890] INFO: task exim4:15225 blocked for more than 120 seconds. Oct 17 16:39:21 sp5059b kernel: [2448749.835915] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 17 16:39:21 sp5059b kernel: [2448749.835947] exim4 D 0f35bdb1 0 15225 15223 Oct 17 16:39:21 sp5059b kernel: [2448749.835951] c24032c0 00000082 c1fdbfc0 0f35bdb1 00089b8e c240344c c1fdbfc0 00000001 Oct 17 16:39:21 sp5059b kernel: [2448749.835956] 00000000 00000001 000013fa 00000000 00000000 00000000 00000246 c0131ba7 Oct 17 16:39:21 sp5059b kernel: [2448749.835962] f77dc400 e6185f20 f77dc450 0039e41c f8899e28 f77dc414 00000000 c24032c0 Oct 17 16:39:21 sp5059b kernel: [2448749.835967] Call Trace: Oct 17 16:39:21 sp5059b kernel: [2448749.835978] [<c0131ba7>] prepare_to_wait+0x12/0x4d Oct 17 16:39:21 sp5059b kernel: [2448749.835986] [<f8899e28>] log_wait_commit+0x8b/0xd1 [jbd] Oct 17 16:39:21 sp5059b kernel: [2448749.835996] [<c0131a98>] autoremove_wake_function+0x0/0x2d Oct 17 16:39:21 sp5059b kernel: [2448749.836001] [<f8896451>] journal_stop+0x12f/0x151 [jbd] Oct 17 16:39:21 sp5059b kernel: [2448749.836009] [<f892f0b7>] ext3_sync_file+0x57/0x9c [ext3] Oct 17 16:39:21 sp5059b kernel: [2448749.836022] [<c015744c>] filemap_fdatawrite+0x12/0x16 Oct 17 16:39:21 sp5059b kernel: [2448749.836027] [<c018f5b5>] do_fsync+0x41/0x83 Oct 17 16:39:21 sp5059b kernel: [2448749.836031] [<c018f614>] __do_fsync+0x1d/0x2b Oct 17 16:39:21 sp5059b kernel: [2448749.836034] [<c01038d2>] syscall_call+0x7/0xb Oct 17 16:39:21 sp5059b kernel: [2448749.836041] =======================
这听起来像你可能在目录中有大量的文件。 我已经看到非常相似的症状，你说的非常大的目录。
可能有某种问题（可能是logrotate的configuration问题），最终导致数百万个文件。 一旦你进入了数百万，大多数文件系统开始有问题。 只要做一个ls就可以花费很多时间，如果你等待足够长的时间，甚至可能会死亡。 像rm这样的命令也会由于文件数量太多而产生问题。 类似的，像logrotate这样的东西似乎会挂起，因为在目录上执行简单的操作将需要很长时间才能完成。
validation这一点的一种方法是在上面的目录（/ var / log / apache2 /）上执行ls -l ，并查看目录条目的大小（而不是内容）。 例如（从我有一个服务器，有几个目录有很多文件）：
$ 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
请注意目录条目的大小与其中的文件数量的比较。
你最好的select是尝试find类似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文件），并build议您有该目录中的数百万个文件。
这应该是在服务器故障 ，但：
您的目录上的读取位似乎closures：使用类似chmod a+r 目录名来更正它。
这是目录创build时最有可能发生的; 日志轮换脚本是否做到这一点？ 这个脚本的多个并发实例完全可能会导致问题，但我很惊讶它会在目录上创build权限问题。 无论如何，你需要一个更快的方法来旋转，并可能有一个机制，以防止在脚本已经运行时启动。
挂任务是一个非常严重的错误。 这是非常严重的proc文件称为/ proc / sys / kernel / hung_task_panic自动恐慌/重新启动。 这意味着一个进程已经挂在内核很长一段时间，这在正常使用情况下不应该发生。
这个问题似乎已经解决了自己??！
我注意到服务器上的负载已经从大约70的高峰平均值回落到1-3左右（通常位于此处）。
我跑了：screen rm -rf vhosts
大约半小时后回来，试图恢复屏幕，什么也没有。 好极了！ 该目录已被删除。
真的没有人知道发生了什么事情，但至less有一部分问题没有了。
没有更奇怪的内核错误。