バックグラウンド
私は小さなlogrotateの失敗を経験しました... Logrotateは、ミスによってアーカイブされたログを回転させ、私のファイルを二次的に増大させました/var/log/
。そして、何かがおかしくなって、/var/log/
すでに数百万個のファイルが含まれていることに気づいたときには...
私はなんとかして(いくつかのヘアロスとfind / sed / grepマジックの後)問題のあるファイルをすべて削除し、logrotateの設定を修正しました。そして、すべてが順調だと思った...
問題
I ls
/ du -hs
またはその他の方法でリストを作成すると/var/log/
(現在は80 MBのアーカイブ/ログと最大で数百のファイルが含まれています)、それを行うプロセスは1、2分ハングします。これはどういうわけか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