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

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

今日、/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。次に、さらに詳しく調べるために、同じ回答からこのスクリプトを実行しました。

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

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

次に、この回答（より深い理解のためにこれを確認することをお勧めします）から、私は実行しました、

sudo su -
> kern.log
> syslog

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

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

最後の注意点として、問題のあるファイル（kern.logおよびsyslog）は、grep内部のファイルの検査（ヘルプ）が/etc/logrotate.d/示すように、ローテーションされるように設定されてい ます。

更新2

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

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

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

最短の方法：

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

rootでない場合、が必要になりますsudo。AUに関する別の回答から引用。

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

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

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

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

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

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

システムログファイルをきれいにする私の方法はこれです。ステップ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スクリプトによって毎週実行されます。

今日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

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