web-dev-qa-db-ja.com

非常に大きなログファイル、どうすればよいですか？

（ この質問 同様の問題を扱っていますが、ローテーションされたログファイルについて説明しています。）

今日、非常に少ない/varスペースに関するシステムメッセージを受け取りました。

いつものように、Sudo apt-get cleanの行でコマンドを実行しましたが、シナリオはわずかに改善されました。次に、ローテーションされたログファイルを削除しましたが、改善はほとんどありません。

調べてみると、/var/log内のいくつかのログファイルが非常に巨大なものに成長していることがわかりました。具体的には、ls -lSh /var/logは、

total 28G
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 kern.log
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 syslog
-rw-rw-r-- 1 root              utmp    390K Aug 23 21:47 wtmp
-rw-r--r-- 1 root              root    287K Aug 23 21:42 dpkg.log
-rw-rw-r-- 1 root              utmp    287K Aug 23 20:43 lastlog

ご覧のとおり、最初の2つは問題のあるものです。このような大きなファイルがローテーションされていない理由に少し驚いています。

だから、私は何をすべきですか？これらのファイルを削除してから再起動しますか？または、より慎重な手順に進みますか？

Ubuntu 14.04を使用しています。

更新1

そもそも、システムはほんの数か月前のものです。ハードディスクがクラッシュしてから数か月前にシステムを最初からインストールする必要がありました。

この回答 でアドバイスされているように、まずtailを使用して問題のあるログファイルをチェックしました。次に、より詳細な検査のために、このスクリプトを same answer から実行しました。

for log in /var/log/{syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

このプロセスには数時間かかりました。出力は次の行にありました。

/var/log/syslog :
71209229  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
53929977  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
17280298  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 54763121030042024)
       <snipped>

/var/log/kern.log.1 :
71210257  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
71209212  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 954763121030042024)

（/dev/sda3は私のホームディレクトリです。見つけることができるように、

lsblk /dev/sda
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0 122.1G  0 part /
├─sda2   8:2    0   7.6G  0 part [SWAP]
└─sda3   8:3    0 801.8G  0 part /home

プロセスが制限を超えて書き込みたい理由は、実際には私の理解の範囲外です。システムの更新後も継続する場合は、このフォーラムで別の質問をしたいと思うかもしれません。）

次に、 this answer （より深く理解するために this をチェックすることをお勧めします）から、私は実行しました、

Sudo su -
> kern.log
> syslog

現在、これらのファイルのサイズはゼロです。システムは再起動の前後に正常に動作しています。

数日中にこれらのファイルを（他のファイルとともに）監視し、報告する必要があります
それらはアウトラインで動作します。

最後の注意点として、問題のファイル（kern.logとsyslog）は両方とも、/etc/logrotate.d/内のファイル（grepの助け）の検査が示すように、回転するように設定されています。

更新2

ログファイルは実際にローテーションされます。大きなサイズは1日で達成されたようです。

filesystemsystemlog
32
Masroor

これらのファイルを削除してから再起動しますか？

いいえ。空にしますが、rmコマンドを入力して再作成するときに何かがクラッシュする可能性があるため、touchは使用しないでください。

最短の方法：

cd /var/log
Sudo su
> lastlog
> wtmp
> dpkg.log 
> kern.log
> syslog
exit

ルートでない場合、Sudoが必要になります。別の answer AUから取得。

それをする前に。 tail {logfile}を実行し、それらが非常に大きくなる理由があるかどうかを確認します。このシステムが数年前でない限り、この理由はないはずであり、問​​題を修正することはこれを継続させるよりも良いでしょう。

通常、kern.logとsyslogはどちらもそれほど大きくないはずです。しかし、私が言ったように、このシステムが何年も稼働している場合は正常であり、ファイルをクリアするだけで済みます。

そして、将来的にそれが大きくなるのを防ぐために：setup logrotate。それは非常に簡単で、設定したサイズより大きくなるとログファイルを圧縮します。

もう1つ：コンテンツを削除したくない場合は、ファイルをtar圧縮またはgzip圧縮して圧縮できます。その結果、おそらく現在の10％のファイルになってしまいます。ディスク上にそれを行う余地がまだある場合です。

38
Rinzwind

lessコマンドまたはtailコマンドを使用して、単にログを視覚的に調べることにより、ログに何が書き込まれているかを確立することを試みる価値があるでしょう。

tail -n 100 /var/log/syslog

または問題のある線があまりにも深く埋まっていて、何が起こっているのかを簡単に確認できない場合、

for log in /var/log/{dmesg,syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

（注：このような大きなファイルの場合、これには時間がかかる場合があります）タイムスタンプを取り除き、最も頻繁に発生するメッセージをカウントしようとします。

19
steeldriver

システムログファイルをきれいにする私の方法はこれです。ステップ1と2はオプションですが、古いログを確認する必要がある場合があり、バックアップが役立つ場合があります。 ;-)

  1. オプション：ログファイルのコピー

    cp -av --backup=numbered file.log file.log.old

  2. オプション：ログのコピーでGzipを使用する

    gzip file.log.old

  3. クリーンなファイルには/ dev/nullを使用します

    cat /dev/null > file.log

そして、このログ（いくつかのサーバーのみ）でlogrotateを使用し、*。1（または次のローテーション）を持つすべてのファイルをgzipで圧縮するcronスクリプトで毎週実行します。

8
zorbon.cz

今日Ubuntu 16.04をインストールしましたが、同じ問題に気付きました。ただし、busybox-syslogdでこれを修正しました。うん！そのパッケージをインストールしたばかりで、問題は解決しました。 :)

$ Sudo apt-get install busybox-syslogd

そのパッケージをインストールした後、syslogとkern.logをリセットします。

Sudo tee /var/log/syslog /var/log/kern.log </dev/null

この簡単な解決策が周りの人々に役立つことを願っています。

3
omluce