12

I have an 80 GB HDD without any partitions. One day I realized that I had lost most of my free disk space. I discovered that /var/log/kern.log.1 takes up 25 GB of space, and there is no delete option for that file.

Here is a screenshot of the problem:

20130110-125652

I am new to Ubuntu/Linux. Please Help. Thank You.

xiota
  • 4,849
Abhishek Prakash
  • 277
  • How large are the other kern.log-files in this directory? Is kern.log.1 the only large file? – qbi Jan 10 '13 at 08:15
  • yes kern.log.1 is the only large file, others are in the range of few mb – Abhishek Prakash Jan 11 '13 at 08:13
  • In general it might be save to delete the file as @elias suggested. However such a large log is usually a hint that there is or was a problem. So you should monitor if your system produces such a large file again. If yes, you should look into the file. – qbi Jan 11 '13 at 11:15

4 Answers4

9

You should be fine removing that file, cause it's an already rotated log. As you need root permissions to do that, you won't have an option in the GUI to delete that file.

You can do it from the command line:

sudo rm /var/log/kern.log.1

Each time you boot, log files will be created and rotated again, so you should probably watch for the next kern.log.* file sizes. Related bug report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/115774

elias
  • 1,159
7

syslog

  • To prevent excessively large log files in the future, edit /etc/logrotate.conf to limit the number and size of log files. See man logrotate for more info.

systemd

xiota
  • 4,849
1

After finding that syslog and kern.log file were increasing, I ran out of disk space. Disk space manager showed me that /var/log folder was taking a lot of space. When I ran command

tail -15 syslog

I found repeating errors. Also syslog and kern.log file took 19 and 32 G respectively. (command for disk usage: du -h filename -h for human readability).

Deleting these files is safe, for those will recreated by the system. But if you need log record of weeks before, don't, for those aren't duplicated.

Note (Only suggestion):

1) If you are unaware of the linux file system then this is the good link: https://help.ubuntu.com/community/LinuxFilesystemTreeOverview

2) More information about log files: https://help.ubuntu.com/community/LinuxLogFiles

Going through these links will clear a lot of concepts.

K7AAY
  • 17,202
Delsilon
  • 145
  • 10
  • Thank you, lots of useful info for a Linux beginner like me. The info is out there...finding it is the problem! – B.Tanner May 24 '18 at 07:47
  • Finding it is also a problem. If you google Linux File System documentation then also it doesn't show the above documentation. It is only visible when you type linux file system tree overview documentation. Finding the right keyword for googling is very difficult for me. Interestingly, I am also a beginner ;) – Delsilon May 24 '18 at 08:59
  • Lots and lots of other interesting articles in the above link's parent directory, ie. https://help.ubuntu.com/community There goes my spare time for the next few days! – B.Tanner May 24 '18 at 09:40
  • Truly man I didn't look into that thing. I feel like I found some golden stuff. Thanks for showing me that thing. Currently I am working on a totally different project but Linux stuff is eating my whole time. – Delsilon May 24 '18 at 10:10
1

kern.log.1 is just one of many of the kernel log files.

Together they and the messages.log.x group can take up many Gb. The rest of the log files in the directory take up about 1% of the total so there is no need to try to mass-wipe the log directory. It might even be harmful to your system..

To reclaim that 99% here are two commands that will do the trick by deleting the unnecessary multi-GB files:

sudo rm /var/log/kern* &>/dev/null
sudo rm /var/log/messages* &>/dev/null

These files will be created again the first time they are needed.

To answer your question specifically: You can set up a cron job to delete them at each midnight, or once a week, whichever.

I use them plus

rm -rf ~/.cache/chromium/Default/Cache/* &>/dev/null

for my midnight rsync backup from the primary /dev/sda SSD to the larger /dev/sdb HDD. It saves on space and they are unnecessary in any kind of restore scenario.

SDsolar
  • 3,169
  • 1
    It's not true that this behavior is build into Linux. The Linux kernel just writes these log message into internal (in-memory) buffers for user-space applications to access. It's some syslog daemon that then pull these logs and writes them to /var/log. That daemon an very well be configured or even turned off completely. – Dreamer Nov 06 '17 at 08:56
  • Point well taken. There are a lot of log messages that are necessary for advanced developers so I don't suggest shutting it off entirely. I run a nightly rsync backup from the /dev/sda SSD to the large /dev/sdb HDD, and in order to make the best use of space I have it do the above, plus also rm -rf /home/pi/.cache/chromium/Default/Cache/* &>/dev/null since none of them are necessary in the restore scenario. – SDsolar Nov 08 '17 at 00:01
  • 1
    I usually run these two following command before reboot: find /var/log/ -type f \( -name "*.gz" -o -name "*.1" -o -name "*.old" \) -delete and find /var/log/ -type f -exec truncate -s 0 {} \; this cleans out the whole /var/log without removing the main files, because some files in there do not get auto generated again. – Videonauth Nov 08 '17 at 00:05