Announcement

**joneall** · Feb 01, 2020, 08:21 AM

Mistaken culprit

I think the real culprit was apt-get. Snooping around with baobab (Does that have another name in KDE?), I found that /var/log/apt/cache was occupying 15.6GB of disk space. I ran "apt-get autoremove" and it dropped to 4.6GB!

Does Discover not handle that correctly? I know if I do my updates by hand (apt-get dist-upgrade), I always do autoremove right afterward.

**kubicle** · Feb 01, 2020, 08:31 AM

Originally posted by joneall View Post

I think the real culprit was apt-get. Snooping around with baobab (Does that have another name in KDE?), I found that /var/log/apt/cache was occupying 15.6GB of disk space. I ran "apt-get autoremove" and it dropped to 4.6GB!

Does Discover not handle that correctly? I know if I do my updates by hand (apt-get dist-upgrade), I always do autoremove right afterward.

Are you sure you ran 'autoremove' and not 'autoclean' (which is an apt command to trim the local package cache...see 'man apt-get' for commands 'autoclean' and 'clean')...as 'autoremove' shouldn't do anything to the package cache. You can keep the cache size down to acceptable levels by running 'autoclean' or 'clean' periodically (like a cron job).

**chimak111** · Feb 01, 2020, 09:40 AM

My notes have
sudo apt autoclean removes debs from /var/cache/apt/archives for software that has been uninstalled
sudo apt clean is stronger and removes all debs in /var/cache/apt/archives

I don't use Discover (much) and can't remember if it cleans up /var/cache/apt/archives automatically.

sudo apt autoremove only removes files that aren't needed by any other installed software.

**kubicle** · Feb 01, 2020, 10:03 AM

Originally posted by chimak111 View Post

My notes have
sudo apt autoremove only removes files that aren't needed by any other installed software.

Or more accurately, it uninstalls packages that were installed automatically as dependencies for another package, but are not needed anymore (because no installed packages depend on them anymore...this might be because of changed dependencies or because the package that depended on them has been uninstalled)

**chimak111** · Feb 01, 2020, 10:49 AM

And I just checked using Discover on 20.04: the debs remained in/var/cache/apt/archives. So running sudo apt clean would make sense when using Discover. I've got used to running it after installing/updating software via the command line.

**chimak111** · Feb 01, 2020, 11:11 AM

Originally posted by kubicle View Post

Or more accurately, it uninstalls packages that were installed automatically as dependencies for another package, but are not needed anymore (because no installed packages depend on them anymore...this might be because of changed dependencies or because the package that depended on them has been uninstalled)

+1

Also, if you use the terminal, the system will prompt the user if there are packages to be "autoremoved".

As an aside, there was some back and forth a few years ago about whether the system would automatically remove debs from /var/cache/apt/archive after a successful update/install, if the user used apt instead of apt-get.

**GreyGeek** · Feb 01, 2020, 11:45 AM

on my 20.04 system the sum of all kernel logs is 6.1 MB.

https://wiki.debian.org/AppArmor/How...%2FDebug#Debug

However, contrary to the advice giving in that link to disable apparmor I'd use

systemctl disable apparmor.service

Code:

$ systemctl status apparmor.service
● apparmor.service - Load AppArmor profiles
     Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
     Active: active (exited) since Sat 2020-02-01 11:24:06 CST; 22min ago
       Docs: man:apparmor(7)
             [URL]https://gitlab.com/apparmor/apparmor/wikis/home/[/URL]
   Main PID: 748 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 18912)
     Memory: 0B
     CGroup: /system.slice/apparmor.service

Feb 01 11:24:06 Aspire-V3-771 systemd[1]: Starting Load AppArmor profiles...
Feb 01 11:24:06 Aspire-V3-771 apparmor.systemd[748]: Restarting AppArmor
Feb 01 11:24:06 Aspire-V3-771 apparmor.systemd[748]: Reloading AppArmor profiles
Feb 01 11:24:06 Aspire-V3-771 apparmor.systemd[766]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Feb 01 11:24:06 Aspire-V3-771 apparmor.systemd[777]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd

**joneall** · Feb 01, 2020, 11:56 AM

I just tried it.

Code:

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
libllvm8 linux-headers-4.15.0-72 linux-headers-4.15.0-72-generic linux-image-4.15.0-72-generic
linux-modules-4.15.0-72-generic linux-modules-extra-4.15.0-72-generic
xserver-xorg-video-intel-arbiter xserver-xorg-video-intel-native-modesetting
Use '[B][I]sudo apt autoremove[/I][/B]' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So it suggests 'apt autoremove', neither 'apt-get' nor 'autoclean'.

So if I understand correctly, the consensus seems to be to run 'apt-get autocleane' after upgrading?

**kubicle** · Feb 01, 2020, 12:22 PM

Originally posted by GreyGeek View Post

systemctl disable apparmor.service

Apparmor provides extra security for linux systems, disabling it just because it writes log messages is somewhat overkill. If logging is excessive one can, for example, forward apparmor's log messages to a separate log in ryslog configuration (that's rotated more often in logrotate configuration) or even forward them to /dev/null (which, of course, sort of fights the idea of logging, but can be done).

Originally posted by joneall View Post

So it suggests 'apt autoremove', neither 'apt-get' nor 'autoclean'.

So if I understand correctly, the consensus seems to be to run 'apt-get autocleane' after upgrading?

As mentioned, autoremove and autoclean/clean do different things. If you wish to clear the package cache in /var/cache/apt, you use autoclean/clean depending on whether you only wish to clear packages that are not available in the repos anymore or all cached packages.

And there is usually no need to clean/autoclean after every upgrade, periodic cron job once a week or perhaps onece a month should keep the package cache in a manageable size.

**Don B. Cilly** · Feb 01, 2020, 01:34 PM

I checked the disk space.
After apt autoremove (which I do quite often), it cleared about 100MB of space - mainly one old kernel.
After apt autoclean (which I hardly ever do) it cleared some half-a-~~pint~~gig of about one gig it had in /var/cache/apt/archives

**kubicle** · Feb 01, 2020, 01:50 PM

Originally posted by Don B. Cilly View Post

After apt autoremove (which I do quite often), it cleared about 100MB of space - mainly one old kernel.

Autoremove uninstalled the unnecessary kernel package, and deleted the files that were installed by that package, thus freeing some disk space from the filesystem. However, it does not clear the downloaded .deb file from the apt cache (in /var/cache/apt/archives) if it is still cached (hasn't been cleaned/autocleaned)

Originally posted by Don B. Cilly View Post

After apt autoclean (which I hardly ever do) it cleared some half-a-~~pint~~gig of about one gig it had in /var/cache/apt/archives

Autoclean cleared all obsolete cached packages, freeing the disk spaced used by these deb files. "apt clean" would clean them all, freeing the remaining 0.5 gig

**Don B. Cilly** · Feb 01, 2020, 04:03 PM

Originally posted by kubicle View Post

Autoclean cleared all obsolete cached packages, freeing the disk spaced used by these deb files. "apt clean" would clean them all, freeing the remaining 0.5 gig

Yeah well, I vaguely figured... if autoclean still keeps the other half-pint, it must be for some reason... I have enough gallons of storage left in the cellar...

**kubicle** · Feb 02, 2020, 02:37 AM

Originally posted by Don B. Cilly View Post

if autoclean still keeps the other half-pint, it must be for some reason.

By default, "autoclean" will keep debs that are still available in the repos in the cache (it can be configured to also keep debs that are installed, but no longer available in the repos). The use case for the cached debs is that you can reinstall these packages from the cache without the need to (re)download them from the repos. Of course, usually the need to (re)download the packages from the repos is not really an issue in case you need to reinstall a package. But whether you should use clean or autoclean is a matter of personal preferences/needs. One could use "clean" if the root filesystem (or the filesystem containing /var) is really starved for space, otherwise "autoclean" should suffice quite adequately.

**Don B. Cilly** · Feb 02, 2020, 02:48 AM

Valuable information. Thanks.

Announcement

apparmor filling kern.log

[SOLVED] apparmor filling kern.log

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment