巨大な39.5GBの/ var / log /フォルダーからスペースを解放するにはどうすればよいですか？

46

デフォルトのディスク分析ソフトウェア（Baobab）から、ハードドライブに1GBしか残っていないというメッセージを受け取りました。いくつかの検索の後、/var/log/フォルダがこの原因であることがわかりました。

以下のファイル/サイズ/var/log/：

kern.log = 12.6 GB
ufw.log = 12.5 GB
kern.log.1 = 6.1 GB
ufw.log.1 = 6.0 GB

等々。/var/logは巨大。

それらのファイルまたは/var/logフォルダー全体を削除できますか？それとも、Ubuntuでは大丈夫ですか？

disk-usage logging

— ブレード19899
ソース

39

フォルダ全体を削除することはできませんが、システムに影響を与えることなく「古いパック」ログファイルを削除できます。

一般的なホームユーザーの場合、圧縮され、拡張子が.gzのログファイルを削除しても安全です（図を参照）。

これらの圧縮ログファイルは、ストレージスペースを減らすためにgzip圧縮された古いログであり、平均的なユーザーとしては必要ありません。

.gz拡張子を選択

— サリー・エミン
ソース

7

find / var / log -type f -name "* .gz" -exec rm -f {} \;

— diyism

@diyism私はあなたのコードを試しましたが、あまり助けにはなりません。私のログディレクトリはまだ6GBのスペースを使用しています@ _ @

— GusDeCooL 14年

1

find /var/log -type f -name "*.gz" -delete、圧縮ファイルを削除し、約1 GBのスペースのみを解放しました。/dirと残りのディスクには50 GBで十分ではありません/home！

— ムハンマドゲルバナ14

母のPCには、サイズが21 GBのkern.logファイルがありました。大きなkern.logは、Linuxカーネル自体または処理中に問題が発生している問題を示しています。どちらの場合でも、Linuxシェルターミナルに移動して、cat /var/log/kern.logまたはnano /var/log/kern.log（GUIで、たとえばgedit /var/log/kern.logまたはのようなものを実行してmousepad /var/log/kern.log）問題を確認します。何が問題なのかを理解したらsudo rm /var/log/kern.log ; sudo telinit 6、そのような（大きな）ファイルを削除してオペレーティングシステムを再起動するために実行できます。

— ユーリスクピラ

私の場合、これは41個のファイルのうち15.7 MBのみを削除します。ここでの実際の問題は、messages（7.7 GB）、user.log（7.7 GB）、syslog（4.1 GB）、およびsyslog.1（3.5 GB）です。これらの4つのファイルの合計は23 GBです。それらを削除する方法、または少なくともサイズを小さくする方法はありますか？

— ロドリゴ

32

/ var / logフォルダー全体を削除することはしません。

@jrgが示唆するようにログを破棄できますが、ログファイル（ほとんどの場合syslogd）への書き込みが再開されない限り、実際にディスクスペースを取り戻すことはできません。ファイルは削除された状態でファイルハンドルは閉じられています。

より良いのは、ログがローテーションされていない（そして後で削除されない）理由を見つけることです。logrotateはこれをあなたに代わって行うことになっており、毎晩実行されるべきではないのではないかと思う。

私が最初にすることは次のとおりです。

sudo /etc/cron.daily/logrotate

これにより、ログファイルがローテーションされます（したがって、kern.logはkern.log.1になります）。その後、kern.log.1などを削除して、ディスクスペースを解放できます。

これまでのところすべてが順調であれば、次の質問は、なぜこれが自動的に行われないのかということです。夜にコンピューターの電源を切る場合は、anacronがインストールされていることを確認してください。

— richvdh
ソース

17

ログを見て、何が書き込まれているのかを確認する必要があります。私の推測ではufw / iptablesです（すべてのネットワークトラフィックを記録しています）。

ufw-すべてのパケットをログに記録すると、大きなログが取得されます。ログを確認しない場合は、ログをオフにします。ネットワークを監視する場合は、snortを使用します。Snortは、受信した数千のパケットをフィルタリングし、潜在的に問題のあるトラフィックを警告します。

ufwが原因であり、kern.logに大きなログが記録されているのは、パケットをそこに記録しているためだと思います。

時々、ログを満たすカーネルまたはハードウェアの問題があります。その場合、問題を修正するかバグを報告するのが最善です。そのためにはログを確認する必要があります。

問題を解決できない場合は、ログがいっぱいにならないようにsyslogを構成できます。

http://manpages.ubuntu.com/manpages/precise/man5/syslog.conf.5.htmlを参照してください

問題の詳細を提供していただければ、デバッグの改善に役立ちます。

— パンサー
ソース

2

それは非常に良い点です。ログを単に削除するのではなく、何がログを詰まらせているのかを知る価値があります。+1。

— -richvdh

6

削除すること/var/logはおそらく悪い考えですが、個々のログファイルを削除しても大丈夫です。

私のラップトップでは、小さなSSDディスクを使用して、次の行を次の行に追加して、マウントポイントとしてセットアップします/var/log（/tmpおよび/var/tmp）。tmpfs/etc/fstab

temp        /tmp        tmpfs   rw,mode=1777    0   0
vartmp      /var/tmp    tmpfs   rw,mode=1777    0   0
varlog      /var/log    tmpfs   rw,mode=1777    0   0

これは、これらのディレクトリに再起動後も何も残っていないことを意味します。私の知る限り、このセットアップは問題なく動作します。もちろん、古いログを調べて発生する可能性のある問題を診断する機能は失われますが、ディスク使用量を減らすための公正なトレードオフだと考えています。

私が経験した唯一の問題は、一部のプログラム（特にAPT）がログをサブディレクトリに書き込みたいため、それらのディレクトリが/var/log存在しない場合にそれらを作成するほど賢くないことです。行mkdir /var/log/aptを追加して、/etc/rc.local特定の問題を修正しました。インストールしたソフトウェアに応じて、他のディレクトリも作成する必要があります。

（別の可能性はtar、ディレクトリのみを含む単純なアーカイブを/var/log作成し、起動時にそれを展開して必要なすべてのディレクトリを作成し、それらのパーミッションを一度に設定することです。）

— イルマリ・カロネン
ソース

1

ufwが問題だったようです助けてくれてありがとう:)

— blade19899