おはようございます、* nixファンの皆さん!
私はしばらくの間Debian 7を使用していますが、最近のアップグレード後、ルートパーティションのスペースが常に不足し続けていることに気付きました。つまり、ディスクに「0」バイトが残っているということです。つまり、lotを検索した後、/ var/logフォルダーをゼロにすることができました。 ls -s -S
このフォルダにファイルをサイズ順に配置すると、3つのファイルのサイズがGB(13〜15 GBなど)であることがわかりました。
はい、logrotate
は正常に動作しています。ログをローテーションしています。たとえば、/ var/logにkern.log.1などがあります。問題は、ログが非常に高速でいっぱいになり、logrotateが実行できないことです。
どうやら、OSの一部のロギングプロセスは、継続的なエラーまたは何か(??)が原因である可能性がある大量のデータを書き込んでいます。知りません。私が知っているのは、この一定の書き込みプロセスが原因で、処理が大量に行われているだけでラップトップが過熱しているということだけです常時。そのため、CPU能力とディスク容量が失われています。
私の質問は次のとおりです。この問題を引き起こしているプロセス/デーモンを特定するにはどうすればよいですか?どうすれば問題の根本原因になり、それを修正できますか? これらの巨大なログファイルを読み取ることはオプションではありません。既に使用中のラップトップでリーフパッドやメモ帳などのテキストエディターで15 GBのログファイルをプルアップしようとすると、開くのに何年もかかります。それは現実的ではありません。
これを引き起こしているプロセス/デーモンがある可能性があるため、この質問は広いと思いますが、誰かがこれを以前に経験したことがあるかどうか、そして通常の疑いがあるかどうかを確認できます。
更新:
エリックの助言に従って、私は/ var/log内のファイルを変更時刻ごとに整理しました。最後のファイルは「syslog」でした。だから、私はそれをtail
した。結果:
Apr 10 00:53:37 MyMachine kernel: [11608.690733] [<ffffffffa08e4005>] ? ath9k_reg_rmw+0x35/0x70 [ath9k_htc]
Apr 10 00:53:37 MyMachine kernel: [11608.690742] [<ffffffff81084f57>] ? process_one_work+0x147/0x3b0
Apr 10 00:53:37 MyMachine kernel: [11608.690750] [<ffffffff81085764>] ? worker_thread+0x114/0x480
Apr 10 00:53:37 MyMachine kernel: [11608.690756] [<ffffffff81556065>] ? __schedule+0x2e5/0x790
Apr 10 00:53:37 MyMachine kernel: [11608.690765] [<ffffffff81085650>] ? create_worker+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690772] [<ffffffff8108ae91>] ? kthread+0xc1/0xe0
Apr 10 00:53:37 MyMachine kernel: [11608.690780] [<ffffffff8108add0>] ? kthread_create_on_node+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690788] [<ffffffff8155a23c>] ? ret_from_fork+0x7c/0xb0
Apr 10 00:53:37 MyMachine kernel: [11608.690795] [<ffffffff8108add0>] ? kthread_create_on_node+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690800] ---[ end trace 12dc8d8439345c1d ]
残念ながら、それは私に多くのヒントを与えません。
あなたが投稿したsyslog
スニペットには、実際に強いヒントがあります。行の終わり
Apr 10 00:53:37 MyMachine kernel: [11608.690733] [<ffffffffa08e4005>] ? ath9k_reg_rmw+0x35/0x70 [ath9k_htc]
スタックトレースは、ath9k_htc
という名前のデバイスドライバーでの予期しないエラーが原因であることが示されています。うまくいけば、カーネルはパニックに陥ることはありませんでしたが、エラーが繰り返し繰り返されてファイルシステムがいっぱいになっています。
次に、このコマンドを使用してath9k_htc
wifiドライバーをブラックリストに登録し、再起動します。
echo "blacklist ath9k_htc" | Sudo tee -a /etc/modprobe.d/blacklist.conf
ただし、エラーにもかかわらずath9k_htc
ドライバーが使用され機能していた場合、wifiが機能しなくなる可能性があることに注意してください。
lsusb
を実行して、ath9k_htc
ドライバーが予期するwifiデバイスがマシンに存在するかどうかを確認し、デバイスがここにあるリストのいずれかに一致するかどうかを確認できます: https:// wiki.debian.org/ath9k_htc
ログファイルが溢れているのを確認するために、ログファイルをエディターで開く必要はありません。最後の数行を見てください。
tail -n 999 /var/log/syslog | less
プロセスのログファイルには、常にプロセスIDが含まれています。
Apr 10 00:00:01 harfang /USR/SBIN/CRON[345]: (root) CMD ( /usr/local/bin/midnight-stuff )
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm bored
これは、wibbled
デーモンのインスタンスであるプロセス1234が大量のログメッセージを生成していることを示しています。あなたはそれを殺してその設定をチェックしたいかもしれません。
kern.log
が大きく成長している場合、ログはプロセスからではなくカーネルからのものです。カーネルログでフラッディングが発生することはまれであり、特定するのが難しくなります。これは、タイトなループで再生成され、すぐにクラッシュするプロセスが原因である可能性があります(システムのメモリが不足している可能性があります)。バグのあるドライバが原因である可能性もあります。原因を理解するには、メッセージを確認する必要があります。
あなたの場合、あなたはドライバーからのバックトレースを見ています。ドライバーは、致命的ではないエラーを継続的に発生しています。それをアンロードしてみてください:
rmmod ath9k
(なぜath9k
?それは関数ath9k_reg_rmw
を提供するドライバーだからですが、実際には、モジュール名が質問に含めたビットから数行先に記載されるためです。)ドライバーがモジュール内にない、またはアンロードできない場合は、モジュールを無効にするか、そのバグのトリガーを停止する別の方法を探してください。それを行う方法は、それがどのドライバーであり、何が問題であるかによって異なります。