20.04 Lack of space on Root

[Robbyx]

I am getting a low space message for the root (/) and would like help to find what is filling up the partiton:

According to pcmanf ,a file manager, the root has used 32.6gb and there is only 683 mb free. I have tried to find out what is making up the 32.6gb and I can only find the 11.5gb used as shown by the disk usage analyser.

There is therefore a mismatch of 21.1gb.

The /home is on a separate partition and uses 28.2gb with 41.6gb free, but the home is not part of the / directory.


blkid shows this extracted portion:

/ was on /dev/nvme0n1p1 during installation
UUID=ed0a7043-7cb0-4710-9175-7f53d26bb6d1 / btrfs defaults,noatime,subvol=@ 0 0
# /home was on /dev/nvme0n1p2
UUID=5bb8aa95-b657-4297-be5b-4352a09596b0 /home btrfs defaults,noatime,subvol=@home 0 0

I am asking for help to find the cause of the very low free space on the root so that I can delete some files. The disprepancy is after running bleachbit.

[crip720]

Usually caused by wonky logs filling up space. Would use sudo with disk management and/or set show hidden files.

[Holger_Gehrke]

As a first step I'd do

sudo du --max-depth=1 --total --one-file-system /

and then I'd drill down into the directories which take the most space.

If the total from the first 'du' only shows something on the same order as your disk usage analyzer, there might be something wrong with the file system. I'd boot a live system from USB and do an fsck (you can't fsck a mounted file system and unmounting / is kind of hard).

My first suspects are log files (if those grow out of control you probably have something bad happening, like failing hardware; so don't erase them before you've read them and found out what's made them grow), older versions of snap packages (snap likes to keep at least one old version of each installed package; with big stuff like the gnome snap two or three such backups can take a lot of space) and the apt package cache.

Holger

[yancek]

This is generally log files, simple command to find the size of files there:

 ls -lh /var/log

[Dennis N]

Check the size of the systemd journal:

dmn@Tyana:~$ journalctl --disk-usage
Archived and active journals take up 2.1G in the file system.

Reduce it if it is growing too big. Here is is reduced from 2.1 GB to approximately 50 MB:

dmn@Tyana:~$ sudo journalctl --vacuum-size=50M
Vacuuming done, freed 2.0G of archived journals from /var/log/journal/49c241b789194be49e33ab171947ef0d.

Comment: Only archived journals were vacuumed (deleted).
New total journal size:

dmn@Tyana:~$ journalctl --disk-usage
Archived and active journals take up 64.0M in the file system.

[tea for one]

Check the size of the systemd journal:

dmn@Tyana:~$ journalctl --disk-usage
Archived and active journals take up 2.1G in the file system.

Reduce it if it is growing too big. Here is is reduced from 2.1 GB to approximately 50 MB:

dmn@Tyana:~$ sudo journalctl --vacuum-size=50M
Vacuuming done, freed 2.0G of archived journals from /var/log/journal/49c241b789194be49e33ab171947ef0d.

Comment: Only archived journals were vacuumed (deleted).
New total journal size:

dmn@Tyana:~$ journalctl --disk-usage
Archived and active journals take up 64.0M in the file system.

@ Dennis N

Thank you for the maintenance tip.
Log files seem to grow exponentially and a bit of judicious trimming is good practice.

[Impavidus]

The user interface of disk usage analyser isn't very intuitive to everybody, but maybe it is to you.

If disk usage analyser doesn't see the files taking all the disk space, there are several possibilities:
- Maybe some files are in directories only readable by root and disk usage analyser has no root privileges;
- Maybe there are files in a directory used as a mountpoint;
- There may be big files that are still open, but deleted. The disk space will be reclaimed when the file is closed;
- Some advanced filesystems, like btrfs, which you use, confuse the simple tools.

My guess is that your problem is specific to btrfs, but I've got no experience with that.

[Robbyx]

As a first step I'd do

sudo du --max-depth=1 --total --one-file-system /

and then I'd drill down into the directories which take the most space.

If the total from the first 'du' only shows something on the same order as your disk usage analyzer, there might be something wrong with the file system. I'd boot a live system from USB and do an fsck (you can't fsck a mounted file system and unmounting / is kind of hard).

My first suspects are log files (if those grow out of control you probably have something bad happening, like failing hardware; so don't erase them before you've read them and found out what's made them grow), older versions of snap packages (snap likes to keep at least one old version of each installed package; with big stuff like the gnome snap two or three such backups can take a lot of space) and the apt package cache.

Holger

I ran your code with -h added in:

sudo du --max-depth=1 --total --one-file-system -h  /
22M	/etc
0	/media
3.1G	/var
138M	/boot
0	/mnt
585M	/opt
904K	/root
88K	/snap
0	/srv
12K	/tmp
7.4G	/usr
0	/cdrom
12G	/
12G	total

The total is roughly equal to pcman's total referred to in my opening post. My reaction is that there is nothing worth clearing out from the directories listed. I am therefore still unclear how to resolve the low space status report.

[Robbyx]

This is generally log files, a simple command to find the size of files there:

 ls -lh /var/log

As far as I can tell the log files are not bloated enough to cause problems with space:

ls -lh /var/log
total 5.7M
-rw-r--r--  1 root              root             484 Jan  8 10:58 alternatives.log
-rw-r-----  1 root              adm                0 Jan  9 00:00 apport.log
-rw-r-----  1 root              adm              429 Jan  8 23:36 apport.log.1
drwxr-xr-x  1 root              root              60 Jan  8 13:21 apt
-rw-r-----  1 syslog            adm             8.1K Jan 10 13:47 auth.log
-rw-r-----  1 syslog            adm             128K Jan  9 23:30 auth.log.1
-rw-------  1 root              root             14K Jan 10 12:55 boot.log
-rw-------  1 root              root             30K Jan 10 00:00 boot.log.1
-rw-------  1 root              root             42K Jan  9 00:00 boot.log.2
-rw-r--r--  1 root              root            102K Jul 31 17:27 bootstrap.log
-rw-rw----  1 root              utmp               0 Jan  1 00:00 btmp
drwxr-xr-x  1 root              root              92 Jan 10 00:00 cups
drwxr-xr-x  1 root              root               0 Jul 21 01:23 dist-upgrade
-rw-r--r--  1 root              adm              92K Jan 10 12:55 dmesg
-rw-r--r--  1 root              adm              91K Jan  9 18:15 dmesg.0
-rw-r--r--  1 root              adm              21K Jan  9 17:38 dmesg.1.gz
-rw-r--r--  1 root              adm              22K Jan  9 15:38 dmesg.2.gz
-rw-r--r--  1 root              adm              23K Jan  8 13:04 dmesg.3.gz
-rw-r--r--  1 root              root             88K Jan  8 13:21 dpkg.log
-rw-r--r--  1 root              root             32K Dec  8 16:53 faillog
-rw-r--r--  1 root              root             12K Nov  1 20:31 fontconfig.log
drwx--x--x  1 root              gdm                0 Oct  7  2019 gdm3
-rw-r--r--  1 root              root            1.3K Jan 10 12:55 gpu-manager.log
drwxr-xr-x  1 root              root               6 Jul 31 17:29 hp
drwxrwxr-x  1 root              root             108 Jan  8 12:30 installer
drwxr-sr-x+ 1 root              systemd-journal  128 Sep 29 17:33 journal
-rw-r-----  1 syslog            adm             124K Jan 10 13:29 kern.log
-rw-r-----  1 syslog            adm             1.9M Jan  9 23:58 kern.log.1
-rw-rw-r--  1 root              utmp            286K Dec  8 16:53 lastlog
drwxr-xr-x  1 root              root               0 Sep  5  2019 openvpn
drwx------  1 root              root               0 Jul 31 17:27 private
drwx------  1 speech-dispatcher root               0 Jan 19  2020 speech-dispatcher
-rw-r-----  1 syslog            adm             457K Jan 10 13:33 syslog
-rw-r-----  1 syslog            adm             1.9M Jan 10 00:00 syslog.1
-rw-r-----  1 syslog            adm             240K Jan  9 00:00 syslog.2.gz
drwxr-xr-x  1 root              root             138 Oct 12 19:04 teamviewer13
drwxr-xr-x  1 root              root             164 Nov  5 22:46 teamviewer15
drwxr-xr-x  1 root              root             28K Jan 10 13:05 timeshift
-rw-------  1 root              root               0 Jul 31 17:27 ubuntu-advantage.log
drwxr-x---  1 root              adm              166 Jan  8 12:30 unattended-upgrades
-rw-rw-r--  1 root              utmp            262K Jan 10 13:01 wtmp
-rw-r--r--  1 root              root             80K Jan  9 17:41 Xorg.0.log
-rw-r--r--  1 root              root             80K Jan  9 17:41 Xorg.1.log

Although the above does not give a total, the properties of the log directory show 207mb as its size

[Robbyx]

Check the size of the systemd journal:

dmn@Tyana:~$ journalctl --disk-usage
Archived and active journals take up 2.1G in the file system.

]

In my case the archived and active journals take up 112.0M in the file system. This is not sufficient to cause the discrepancy.