0

I have installed ubuntu 16.04 two days ago and the root partition space was 25 GB. while i was searching for solutions in one blog I found somebody telling me to check the log folder and delete it. I checked my log and it was almost 17 GB! then I deleted it.Then I run df -h and it showed root partition was 69% used. I run the same command after 2sec and it showed 71%. I ran it at least 15 times in 1 minute and eventually it got 100% full. Root partiton showing full in less than a minute. However I checked the log space after that and it showed empty...

Does this normally happens? If not than what is the solution? I am comparatively new to ubuntu and don't actually know what to do!

output of ls -lah /var/log/

Log description

Jack Frost
  • 1
  • 2
    If the log files are large, maybe you can check what they contain and paste some of the repeating log messages here. – SurvivalMachine Oct 02 '18 at 17:04
  • 1
    Can you add output of command: ls -lah /var/log/ to your question? This might be useful too: https://askubuntu.com/questions/100004/how-can-i-free-space-from-a-massive-39-5gb-var-log-folder – ignite Oct 02 '18 at 17:12
  • What brand/model system? Have you updated UEFI/BIOS to latest version from your vendor? Some Asus models need boot parameter to prevent run-away log files. Asus x555u w/o pci=nomsi - space issue on drive and runaway log files filling drive https://ubuntuforums.org/showthread.php?t=2327103&page=3 & https://ubuntuforums.org/showthread.php?t=2327570 – oldfred Oct 02 '18 at 19:00

1 Answers1

3

It is definitely not normal for your root volume to fill up so quickly. It's almost certainly either a problematic process which is most likely caught in some sort of infinite loop (writing errors to a log somewhere in /var/log/*) Or maybe a task you kicked off is using far more disk space that you expected (often in /tmp) so you need to narrow down what/where is using up the space.

Most likely it's a single file so try running:

find / -size +5G -print

as root which will give you a list of the full paths and filenames of anything over 5 gigabytes. If anything is listed in /tmp or /var (especially /var/log), it's a good bet you've found the problem file. If no files are listed, try running

du -s --one-file-system /*

as root to see how much the top-level directories are using. You can then recursively run this command on the largest result so if /tmp appears to be the problem, next try running:

du -s --one-file-system /tmp/*

and so on until you find the problem directory.

For future reference, a utility I find handy to keep installed is gdmap (http://gdmap.sourceforge.net/ - it's available in the package repos) which will let you quickly visually get a feel of disk usage both by directory and file in a directory tree. Unfortunately, with your root volume filling up as it is, it might not be possible for you to install additional packages right now.

blihp
  • 174
  • Sidenote: when deleting logfiles it may happen that they are not visible any longer via ls -l but still exist (and claim space) because the writing process hasn't closed them yet. The command lsof -nP +L1 may be used to find such deleted-but-still-in-use files. It lists files with less than one link to them together with the owning process. – PerlDuck Oct 02 '18 at 19:08
  • First of all thank you. I probably found it. I think The kern.log file in /var/log location is problematic. It's size showed 18.5 GB. Obviously i couldn't open it in a text editor. So I had to save the tail of the file here https://paste.ubuntu.com/p/GbQfBgKzJk/ can you please have a look? – Jack Frost Oct 03 '18 at 06:28
  • Yep, and it looks like an easy one: you've got a PCIe card in your computer that is causing all your trouble. Assuming you're on a desktop, (temporarily) take out any optional cards you can and re-seat whatever you can to see if the errors stop. If they do and you have one or more cards removed, add them back one at a time. If you only have a video card and re-seating it doesn't work, try moving it to a different slot. (you're trying to narrow down if it's a card, a slot, or the motherboard) – blihp Oct 03 '18 at 06:44
  • That could be a good solution, although I found one here https://askubuntu.com/questions/863150/pcie-bus-error-severity-corrected-type-physical-layer-id-00e5receiver-id/863301 just added the parameter {pcie_aspm=off} to the grub file, updated the grub and rebooted. So far It's working well! – Jack Frost Oct 03 '18 at 18:46