Those files in /var/log/ are text log files (except for the journal; those files are binary but can be read using ‘journalctl’). They collect error and warning messages. That they are growing that fast and to that size is a sign that something is wrong in your system.
For comparison: on my system I’ve limited the journal to store only the last 6 months and it takes up about 2.8 GB. I’ve configured logrotate to keep about a month worth of logs (rotating every week, the current and the previous log are kept as-is, the older logs are compressed). All the text logs take up less than 500 MB.
Having 33 GB of logs means your system is either keeping logs for a very long time or it’s logging a lot of errors and warnings. Read or at least skim those logs to get an idea what’s wrong.
could you give me please a command to reduce/limit/configurate those files?
i installed waydroid and put some rules in order to have internet in waydroid, but i uninstalled waydroid because all this happen, and reinstalled gufw, and still much space…
A better solution is to read a segment of the logfile, understand the problem that the log is describing, and resolve that underlying problem.
Typically you will discover a repeating pattern to the log quickly enough. Usually a minute or two of browsing is all you need. Show us an iteration of that pattern.
Note that the link you provided is too large for Google Drive to preview. Asking us to download an enormous random file is considered a bit shady here.
Please have a cup of coffee and then
reconsider what ian-weisser advised above.
Once the cause of these excessive logging is determined; then corrective action can be taken. If a really have-to case one can manually remove old log files (in the event that log rotate is not enough).
First of all, the vacuuming of the journal will only clean the journal file (sadly Ubuntu still ships two logging mechanisms (rsyslog and journald)) so you only cleaned the systemd side of things…
If you look at the big files (ufw.log, kern.log and syslog) you will likely find that they have rather similar content and given that the ufw.log file is so big I’d guess you have something like the nf_conntrack module enabled in your ufw settings, that will then log a line for each tcp connection from and to the machine…
Check your ufw settings and do not use such chatty settings like conntrack or other traffic monitoring options in your config
It looks like your kernel log is being flooded with AppArmor “DENIED” messages. While these specific logs aren’t massive individually, if your system is constantly throwing these errors (especially from Snaps like Zoom and Whatsie), the log files in /var/log/ can balloon in size and eat up your disk space.
Here is a step-by-step guide to finding what is eating your space and how to clean it up.
1. Identify the Space Hogs
Open your terminal and run this command to see which directories are taking up the most space:
sudo du -sh /var/log /var/cache /home/* | sort -h
If /var/log is huge (several GBs), the logs are your primary culprit.
2. Immediate Cleanup (The “Quick Fix”)
To regain space immediately, you can safely clear out journal logs and package caches.
Vacuum Systemd Logs: This limits your logs to the last 200MB.sudo journalctl --vacuum-size=200M
Remove Old Snaps: Snap keeps old versions of apps. Use this command to clear them:snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do sudo snap remove "$snapname" --revision="$revision"; done
3. Address the Root Cause (The Logs)
Your logs show Zoom and Whatsie (Snaps) are being blocked from accessing certain system files (kdeglobals, vulkan drivers). This triggers a log entry every few seconds.
Fix A: Give Snaps Permission
Sometimes connecting the right “interfaces” stops the errors. Try:
I wouldn’t call that “flooded”, there are a few denials but not in an amount that would count for gigabytes of log spam (note that I am the zoom-client maintainer , the few vulkan and dbus messages on initial app startup are totally normal)
The real issue is likely rather the ufw.log and some mis-configuration of UFW, also tail -f will only give information about the current state but if the OP meanwhile removed and re-installed UFW with new configuration the spamming might have stopped….
@ksso if the tail -f output does not madly scroll but only prints something every once in a while it seems the cause of your log spamming is gone for the moment, if I were you I’d just delete the three files (syslog , kern.log and ufw.log, the respective services will just re-create them when they have something to write again) and watch them over the next few days to see if they will be growing again to unreasonable sizes
