Zorin Core 15.2 bloated to 15GB!

Suddenly this morning I started getting notifications that filesystem root was down to less than 500MB.
Thought that strange as normally have about 5GB headroom within 16GB total. i.e. 11GB used. This has remained stable since first installed Z15.
I have not done a Software update since so, what has gobbled up all my root space.
As for apps, I only have Firefox and Thunderbird other than standard Core items, infact I have removed some apps from Core that I do not use.
I am confused by this sudden increase.
PS I have kernel 5.4.0-42 with 5.3.0.62 as backup.

zabadabadoo wrote:Suddenly this morning I started getting notifications that filesystem root was down to less than 500MB.
Thought that strange as normally have about 5GB headroom within 16GB total. i.e. 11GB used. This has remained stable since first installed Z15.
I have not done a Software update since so, what has gobbled up all my root space.
As for apps, I only have Firefox and Thunderbird other than standard Core items, infact I have removed some apps from Core that I do not use.
I am confused by this sudden increase.
PS I have kernel 5.4.0-42 with 5.3.0.62 as backup.

Try

Code:

sudo apt clean

and you may also use

Code:

sudo apt-get autoremove

to declutter.
I am the same way about removing apps I do not use. That is very odd you would get that message. Let's see if an aptitude scrub has any effect, first before delving deeper.

Thanks @Aravisian for prompt reply.
I will now give that a try.

Since my earlier post, I have been looking at Disk Analyser to try and see the culprit. It tells me I have 4.6GB in the logs folder!

Aravisian wrote:Try

Code:

sudo apt clean

OK that increasd headroom to 1.9GB. Still way less than my nominal 5GB headroom.

Aravisian wrote:and you may also use

Code:

sudo apt-get autoremove

That only gave me another 130Mb.
So I have 1.9GB free from 16GB.

Any Idea why logs is so massive and can that be safely reduced?
within logs, journal is sitting at 1.1GB

Give Stacer a try:



Get it from here:

https://sourceforge.net/projects/stacer/

I am only competent in installing apps from Software and using Synaptic, not via a download.
stacer looks interesting but at the moment can ill afford to add more software into root.
Is there another way to clean out logs etc without installing another app, or is clean and autoremove suggested by Aravisian my only options?

---
More:
I have had a look at bleachbit (installed via Software), just using preview mode. That only seems to indicate approx 400MB of stuff that could be removed, which is only a fraction of the overnight growth.

---
More More:
OK. I have used journalctl to
1) check disk space occupied by journals (was >1G),
2) archive active journal and start afresh by rotating,
3) clean journal to max size of approx 100MB

Code:

journalctl --disk-usage
sudo journalctl --rotate
sudo journalctl --vacuum-size=100M

Then used bleachbit on APT to clean.

I have now 3.2GB of free space in root, which is a bit better than first thing this morning.

I still cant understand the sudden overnight growth. I know a recent software update mentioned snapd and worried that maybe some software could be inflated if snap is now involved.

---
More More More:
Root free space is being eaten up rapidly. Now down to 2.8GB after just a couple of hours. i.e. extra 400MB used.
From Disk Analyser.
syslog is 1.7GB
kern.log is 1.7GB
Log entries are dated today. Why are these logs so BIG?
There seems a lot of flatpak helper entries in syslog.

Could you please paste the following command to look at percentages of Files in terminal, then post the output here:

Code:

sudo df -h

Look near the percentage used on the /dev/sda* line.
Next, the command for looking at the percentage of inode:

Code:

sudo df -i

and also look at the percentages and compare them. If the first command had a much larger percentage, then we know it is files that is taking up so much space. If it is the other way around, or they are near to the same size, then we know that running processes are a culprit.

In my case, it was 3% vs 45%, indicating files take up a lot of space but processes take up little.

Next, let's check if there are any recent errors in the logs that need attention:

Code:

tail -f /var/log/syslog

Just to be sure that we don't end up right back where we started...
Then clean:

Code:

sudo sh -c 'cat /dev/null > /var/log/syslog'

You already cleaned the journlcrtl which was next suggestion, but have you cleaned the kernel logs and removed old kernels that you no longer need?
It is wide to keep one known working backup kernel.

Aravisian wrote:Could you please paste the following command to look at percentages of Files in terminal, then post the output here:

Code:

sudo df -h

Look near the percentage used on the /dev/sda* line.
Next, the command for looking at the percentage of inode:

Code:

sudo df -i

and also look at the percentages and compare them. If the first command had a much larger percentage, then we know it is files that is taking up so much space. If it is the other way around, or they are near to the same size, then we know that running processes are a culprit.

In my case, it was 3% vs 45%, indicating files take up a lot of space but processes take up little.

My percentages were 87% and 35% for h and i

Aravisian wrote:Next, let's check if there are any recent errors in the logs that need attention:

Code:

tail -f /var/log/syslog

Just to be sure that we don't end up right back where we started...
Then clean:

Code:

sudo sh -c 'cat /dev/null > /var/log/syslog'

You already cleaned the journlcrtl which was next suggestion, but have you cleaned the kernel logs and removed old kernels that you no longer need?
It is wide to keep one known working backup kernel.

I only have 2 kernels at the moment as I mentioned in OP.
How do I clean kernel logs?

Edit:
syslog and kern.log still both 1.7GB according to Disk Analyser.

zabadabadoo wrote:My percentages were 87% and 35% for h and i

Yowza.
Looks like something you are running is gobbling up a lot of logspace. You're processes and filespace are pretty high.
You can use this mile-long puppy to look at what your biggest files are:

Code:

dpkg-query --show --showformat='${Package;-50}\t${Installed-Size}\n' | sort -k 2 -n | grep -v deinstall | awk '{printf "%.3f MB \t %s\n", $2/(1024), $1}'

Scan through the results and see if there is anything taking up space that is obsolete, unused or unwanted.
You know... don't go removing wget or anything. Check what anything you consider removing IS before removing.

Also, pkexec into your file manager with elevated permissions, go to Root, then
/root/.cache/thumbnails- you can clean up in there
/root/.local/share/Trash - Can clean up in here
/root/.thumbnails - see if there is anything in here
For your home folder thumbs:

Code:

rm -rf ~/.cache/thumbnails/*

(Always use caution when using the rm -rf Command!!! Ensure that it IS specifying the files you want to remove only before hitting enter)

Truncate kernel logs

Code:

echo > /dev/null | sudo tee /var/log/kern.log

If you use snap for snap-packages, that will hoover up a LOT of space.
If so, you can create a shell script with the following

Code:

#!/bin/bash
# Removes old revisions of snaps
# CLOSE ALL SNAPS BEFORE RUNNING THIS
set -eu
snap list --all | awk '/disabled/{print $1, $3}' |
    while read snapname revision; do
        snap remove "$snapname" --revision="$revision"
    done

Right click it, properties > Make executable.
Then run that puppy.

Did you check the Tail of the Logs as above to see if any errors are causing the pile up of logs or heavier i/o?
Also, when you installed Zorin, what size did you allocate for root?

Aravisian wrote:You can use this mile-long puppy to look at what your biggest files are:

Code:

dpkg-query --show --showformat='${Package;-50}\t${Installed-Size}\n' | sort -k 2 -n | grep -v deinstall | awk '{printf "%.3f MB \t %s\n", $2/(1024), $1}'

Scan through the results and see if there is anything taking up space that is obsolete, unused or unwanted.

Well that was interesting. According to that listing I have about a dozen and a half
linux-modules-extra-x.x.x-xx-generic
listed, going back to 4.18.0-16.
I wonder where hose files are lurking and why they were not removed when kernel was removed. I will go hunting them in the forest tomorrow.

If I delete the 1.7GB syslog and kernel.log files, I have seen elsewhere these log files are regenerated on boot.
I have done several boots today but not seen these log files being rotated or recreated, just same old 1.7GB each.
Maybe different tomorrow. Watch this space.

BTW I have a dual-boot setup and limited to 16GB for root. Zorin say >10GB for 15Core.

zabadabadoo wrote:Well that was interesting. According to that listing I have about a dozen and a half
linux-modules-extra-x.x.x-xx-generic
listed, going back to 4.18.0-16.
I wonder where hose files are lurking and why they were not removed when kernel was removed. I will go hunting them in the forest tomorrow.

I always worry if my efforts are in vain... Then something like this happens. What a discovery. I bet those are hogging up space.

zabadabadoo wrote:If I delete the 1.7GB syslog and kernel.log files, I have seen elsewhere these log files are regenerated on boot.
I have done several boots today but not seen these log files being rotated or recreated, just same old 1.7GB each.
Maybe different tomorrow. Watch this space.

The files, yes, but not necessarily the contents of the log. A new log is created to catch reports, but the existing (or old) reports are removed, decreasing size.

zabadabadoo wrote:BTW I have a dual-boot setup and limited to 16GB for root. Zorin say >10GB for 15Core.

Kind of an opinion based thing, here... Keeping root smaller will force a user to take care of some needed cleaning.
But having root set to 20gigs or more can allow plenty of expansion room.
I really think it depends on what you are using the computer for and what you are running on it.
I run a lot of different apps like Blender and Gimp, as well as doing a lot of testing, so I have more than one desktop installed, several file managers including Nemo, Nautilus, Thunar, Caja... Yet, I kept Root Small and I clean very often.
IF I was anyone else, I would have set root at 30gigs.

Or me at 50!

Swarfendor437 wrote:Or me at 50!

No, Swarf. We are talking about root size, not Age.

So are you telling me I cannot delete "syslog" and "kernel.log" actual files but can delete older ones?

I also have several other log files e.g. Rkhunter logs etc, but they are nowhere near as big as 1.7GB each.
I have not booted the Zorin machine yet today as have other things to do, but plan to have another go at it later today.

Please advise which files I can delete and best way to delete them without causing damage.
Thanks

zabadabadoo wrote:So are you telling me I cannot delete "syslog" and "kernel.log" actual files but can delete older ones?

I also have several other log files e.g. Rkhunter logs etc, but they are nowhere near as big as 1.7GB each.
I have not booted the Zorin machine yet today as have other things to do, but plan to have another go at it later today.

Please advise which files I can delete and best way to delete them without causing damage.
Thanks

No, if you delete the logs, they will be replaced with clean new ones ready to document any new errors.

I would honestly avoid suggesting what files you can or cannot delete without really knowing your machine. While there are many that are generic and safe to delete no matter what, I would really prefer you search each Large File you wish to be rid of first as you are there to see all the details readily. I might make an assumption that makes a big problem for you and I don't want to have that going on.

I'm back and pleased to say I now have much more headroom in filesystem root i.e. 6.2GB free of 16GB total. (was 2.8GB this morning).
I noticed that a new syslog was started but the big 1.7GB boy was now labelled syslog.1, after first reading quickly through it I decided to remove it.
The 1.7GB kernel.log has also gone, but have a fresh one now.
Neither of these files are now growing like jacks beanstalk, but I will keep an eye on them after this little saga.

I have several archive (.gz) logs in the /var/logs folder. I do not plan to delete any more, but would like an opinion whether old .gz archive logs can be removed, as some are retained dated last year. They are:-
alternatives.log.*.gz
auth.log.*.gz
dpkg.log.*.gz
kern.log.*.gz
mail.log.*.gz
rkhunter.log.*.gz
syslog.*.gz
ufw.log.*.gz

I went hunting for those "linux-modules-extra..." files your puppy script threw up yesterday.
I found them in /var/lib/dpkg/info
However when I listed them using
ls -S -l -h
The files in question were just 1.1k not size reported by your script.
To help confirm the ones I found were the ones your script finds, can the puppy script be modified to return the filepath as well as filename of big files?

Anyway. Zorin is now quicker to boot and seems more responsive now it has had a clear out.

zabadabadoo wrote:I have several archive (.gz) logs in the /var/logs folder. I do not plan to delete any more, but would like an opinion whether old .gz archive logs can be removed, as some are retained dated last year.

They can, though they have already been truncated which is why they are .gz.

zabadabadoo wrote:To help confirm the ones I found were the ones your script finds, can the puppy script be modified to return the filepath as well as filename of big files?

Yes, it can, but you also can just use the "locate <FILENAME>" command to locate each in turn to stay organized and take it one at a time.

Aravisian wrote:

Swarfendor437 wrote:Or me at 50!

No, Swarf. We are talking about root size, not Age.

I know - that is what I have - / = 50 Gb.

I am running Zorin 15 Core dual-boot on a 12 year old laptop which has a small HDD even compared to modern SSD's.
After the problems of sudden root space depletion in last 2 days, I have now got it back under control with consistent 6.1GB free within 16GB partition.
I have also had to reinistall "Windows App Support" (POL/Wine) and had difficulty to reinstall a small windows app that was working well under POL before.
All these problems seem to have arisen since update to new linux kernel 5.4.0-42. Coincidence maybe.
Anyhow I seem to be flying straight and level again after some log felling, touch wood (pun intended)
Thanks Aravisian and Swarf for help and inspiration.