背景
我遇到了一个小的logrotate不幸事件... Logrotate会由于错误拍摄而旋转已归档的日志,从而导致我的文件出现二次增长/var/log/
。等到我风起云涌时,那/var/log/
已经有些问题了,已经包含了几百万个文件 ...
我设法(经过一些脱发和查找/ sed / grep魔术之后)删除了所有有问题的文件并修复了我的logrotate配置。认为一切都很好...
问题
每当我ls
(du -hs
或以其他方式)列出其内容/var/log/
(现在包含80mb的存档/日志以及最多几百个文件)的内容时,该过程将挂起一两分钟。我确实认为这与logrotate不幸事件有关,但我不确定,可能还有其他原因。无论如何,我无所适从在哪里开始调试或为此寻找解决方法。请帮忙:3
其他资讯
uname -a
Linux xxx 3.3.8-gentoo #18 SMP Sat Sep 21 22:44:40 CEST 2013 x86_64 Intel(R)
Core(TM)2 CPU 4400 @ 2.00GHz GenuineIntel GNU/Linux
cat /proc/meminfo
MemTotal: 2051552 kB
MemFree: 75612 kB
Buffers: 9016 kB
Cached: 1740608 kB
SwapCached: 0 kB
CFQ IO scheduler + SLUB allocator
我是这样想的:目录中有多少文件太多?(从网络下载数据)是相关的,但我没有剩下的文件了。
编辑
即使在致电后问题仍然存在,init 1
所以我认为可以肯定地认为,除了FS外,没有其他责任可归。
解决方案(从接受的答案中应用)
init 1
mv /var/log /var/log1
mkdir /var/log
chmod --reference=/var/log1 /var/log
chown --reference=/var/log1 /var/log
tar -C /var/log1 -cvp . | tar -C /var/log -xvp
rm -rf /var/log1
init 5