On 10/15/19 3:45 PM, Samuel Sieb wrote: Hi Samuel, I just tried it out. It has a petty interface. I have been using xdiskusage, which has a miserable interface, but it works over "ssh -X". # dnf install baobab How they get baobab out of "Gnome Disk Analyzer" is beyond me. Great tip! -T I always nuke the /home directory and put the extra space to / when I set up Linux. Folks running out of space on / can always fire up gparted and rob space from /home. After a backup, of course

On 10/16/19 1:15 AM, Patrick O'Callaghan wrote: Somebody had way too much fun naming that! Thank you.

On 10/16/19 10:13 AM, home user wrote: 2 things pop out to me. You have a /var/cache/PackageKit/28 directory structure.  Since you're at F30 you should also have a /var/cache/PackageKit/30 directory structure which is now being used.  So, the 28 is no longer being used and can be removed. [egreshko@acer PackageKit]$ pwd /var/cache/PackageKit [egreshko@acer PackageKit]$ ls 30 Is all I have on my F30 systems. And then, /var/cache/abrt-di/usr That most likely contains a bunch of core files that are no longer needed. -- The key to getting good answers is to ask good questions.

On 10/16/19 9:29 AM, home user wrote: If PackageKit is not running, then it won't be creating any files in there. I don't have anything in that directory. In general, anything in /var/cache should be deletable, although something currently running might care about it. In this case, if you don't have any abrt reports that you still want to send in, feel free to delete anything under abrt-di.

(responding to Samuel) done. there can be deleted. bash.49[yum]: ls -la ----- total 16 drwxr-xr-x.  3 root root 4096 May 21 10:44 . drwxr-xr-x. 26 root root 4096 Feb 11  2019 .. drwxr-xr-x.  7 root root 4096 Oct  1  2015 x86_64 bash.50[yum]: cd x86_64/ bash.51[x86_64]: ls -la total 48 drwxr-xr-x.  7 root root 4096 Oct  1  2015 . drwxr-xr-x.  3 root root 4096 May 21 10:44 .. drwxr-xr-x.  9 root root 4096 Aug 21  2013 18 drwxr-xr-x. 11 root root 4096 Jan 20  2014 19 drwxr-xr-x.  9 root root 4096 Mar 26  2015 20 drwxr-xr-x.  9 root root 4096 Sep 22  2015 21 drwxr-xr-x.  9 root root 4096 Oct  1  2015 22 bash.52[x86_64]: ----- done. What's in there. I have no such directory.  Do you mean "/var/tmp"? ----- bash.57[tmp]: pwd /var/tmp bash.58[tmp]: ls -la total 220 drwxrwxrwt. 25 root        root       36864 Oct 16 09:43 . drwxr-xr-x. 22 root        root        4096 Oct 10 15:29 .. drwxr-xr-x. 33 abrt        abrt        4096 Feb 24  2015 abrt drwxr-xr-x.  2 abrt        abrt        4096 Sep 25  2015 abrt-tmp-debuginfo-2015-09-25-09:42:13.2716 drwx------. 23 abrt        abrt        4096 Mar 23  2016 dnf-abrt-hr0XWP drwx------. 16 bill.admin  bill.admin  4096 May  8  2018 dnf-bill.admin-k9id5atu drwx------. 48 weilian.eng bill        4096 Jul 26 20:12 dnf-weilian.eng-1bbrtU drwx------.  2 weilian.eng bill        4096 Dec 16  2013 icedteaplugin-weilian.eng drwx------.  3 bill.admin  bill.admin  4096 Oct 18  2017 kdecache-bill.admin drwx------.  6 root        root        4096 Apr  6  2017 kdecache-root drwx------.  7 weilian.eng bill        4096 Feb 16  2019 kdecache-weilian.eng drwx------.  6 weilian.han bill        4096 Jan 18  2017 kdecache-weilian.han -rw-------.  1 akmods      akmods      1743 Apr  2  2019 rpm-tmp.44YeSR -rw-------.  1 root        root         103 Feb 22  2018 rpm-tmp.5MeXiv -rw-------.  1 akmods      akmods      1743 Mar 31  2019 rpm-tmp.5mmkq4 -rw-------.  1 akmods      akmods      1530 Apr 12  2018 rpm-tmp.7kb9xY -rw-------.  1 akmods      akmods      1743 Apr  3  2019 rpm-tmp.9AoCWH -rw-------.  1 akmods      akmods      1743 Mar 30  2019 rpm-tmp.HtpOcg -rw-------.  1 root        root         104 Jan 24  2019 rpm-tmp.JUUYIy -rw-------.  1 akmods      akmods      1522 Sep  8  2016 rpm-tmp.LD6t8N -rw-------.  1 root        root         102 Dec 28  2017 rpm-tmp.LJfbGv -rw-------.  1 akmods      akmods      1558 May 24  2018 rpm-tmp.PAqjNO -rw-------.  1 akmods      akmods      1743 Apr  1  2019 rpm-tmp.snEYmZ -rw-------.  1 akmods      akmods      1743 Apr  3  2019 rpm-tmp.uafHM0 -rw-------.  1 akmods      akmods      1743 Mar 28  2019 rpm-tmp.uUdIRD -rw-------.  1 akmods      akmods      1743 Mar 31  2019 rpm-tmp.vDOpyE -rw-------.  1 akmods      akmods      1743 Nov 29  2018 rpm-tmp.WLDYHT -rw-------.  1 akmods      akmods      1743 Mar 29  2019 rpm-tmp.XNUHyr -rw-------.  1 akmods      akmods      1743 Mar 28  2019 rpm-tmp.y893lL -rw-------.  1 akmods      akmods      1743 Mar 28  2019 rpm-tmp.zhk0oA -rw-------.  1 akmods      akmods      1743 Mar 29  2019 rpm-tmp.ZZnjcB drwx------.  3 root        root        4096 Jul 29  2014 systemd-colord.service-XvmwnMo drwx------.  3 root        root        4096 Apr  7  2014 systemd-cups.service-X6bMLbk drwx------.  3 root        root        4096 Jul 29  2014 systemd-cups.service-XHj9Z7j drwx------.  3 root        root        4096 May 21  2014 systemd-cups.service-XuxxY3i drwx------.  3 root        root        4096 Oct 16 08:14 systemd-private-791f6fc73b9e4a8bb7b8781d9cce9b0e-bolt.service-bRLder drwx------.  3 root        root        4096 Oct 16 08:00 systemd-private-791f6fc73b9e4a8bb7b8781d9cce9b0e-chronyd.service-f1AhM4 drwx------.  3 root        root        4096 Oct 16 08:01 systemd-private-791f6fc73b9e4a8bb7b8781d9cce9b0e-colord.service-wsFOFW drwx------.  3 root        root        4096 Oct 16 08:00 systemd-private-791f6fc73b9e4a8bb7b8781d9cce9b0e-dbus-broker.service-JOXaTo drwx------.  3 root        root        4096 Oct 16 08:14 systemd-private-791f6fc73b9e4a8bb7b8781d9cce9b0e-fwupd.service-UXEFt0 drwx------.  3 root        root        4096 Oct 16 08:00 systemd-private-791f6fc73b9e4a8bb7b8781d9cce9b0e-rtkit-daemon.service-Gv16Ht drwx------.  3 root        root        4096 Oct 16 08:13 systemd-private-791f6fc73b9e4a8bb7b8781d9cce9b0e-upower.service-NVoJF9 drwx------.  3 root        root        4096 Jul 29  2014 systemd-rtkit-daemon.service-Xc4kzRL -rw-r--r--.  1 root        root           9 Mar 26  2015 system-upgrade.state drwx------.  3 weilian.eng bill        4096 Jul  9  2013 yum-weilian.eng-idPcRP bash.59[tmp]: ----- I can fpaste an "ls -alR" if needed. thanks, Bill.

(responding to Samuel) done. thanks, Bill.

On Wed, 2019-10-16 at 17:35 +0000, sixpack13 wrote: I wouldn't do that. At this time, /var/tmp is expected to be on permanent storage, some things might expect data to remain available. Some things might generate more temp files than your RAM (especially if you burn DVDs or Blurays). If you need to use a temporary file to debug a problem, you lose it during crashes. Better to take a more considered way to clean up *old* files. When they made /tmp use tmpfs, that caused a plethora of such problems. I don't seem to suffer the problems I see commonly mentioned on this list (filling up hard drives, the wrong kernel booting, continually having to manually reconfigure grub, etc), the kind of things that are supposed to take care of themselves, automatically. Probably because I haven't painted myself into a corner by doing oddball things to my system in the first place. -- uname -rsvp Linux 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:46 UTC 2019 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

... journal/ 4.5 GB 101 I do clean up my /var/log/journal/ via following commands (maybe imperfect !): sudo journalctl --flush --rotate; sudo rm -rfv /var/log/journal/*/*@*; sudo journalctl --update-catalog --sync; man journalctl

obviously NOT by an size of 4.5 GB (not MB !)

On 10/17/19 3:11 AM, Samuel Sieb wrote: Totally agree.  I too ran into a situation where it would have been better for the journal to be even larger. -- The key to getting good answers is to ask good questions.

okay, thanks for clarification !

... short answer: ========== one is called "rm". another could be "journalctl --vacuum-something". for the seconds one: I have difficulties to pick what it in what combination does (I need to play with it). But I already have marked in my above comment it could be "imperfect" ! 1. sudo find /var/log/journal -mtime +1 -print0 | xargs -0 sudo rm -rf; 2. sudo journalctl --update-catalog; finds and deletes all journals elder then 24 h and tells the journal catalog to update it's index. - maybe the first "sudo" is superfluous - long answer: ========== please carefully read "man journalctl" and my commands I provided esp. "sudo rm -rfv /var/log/journal/*/*@*;" it only removes elder(!) "archive" journal files. elder files are all which carries a "@" in it's name ! the current journal files are starting with "system" and "user" in it's name are untouched ! current journal files and archives do I generate with "--rotate" from manpage: "Asks the journal daemon to rotate journal files. ... Journal file rotation has the effect that all currently active journal files are marked as archived and renamed, ..." => the files with "@" in it's name ! "--flush" dito manpage: "Asks the journal daemon to flush any log data stored in /run/log/journal/ into /var/log/journal/" I guess "/run/log/journal/" is a/are the log file(s) in RAM. the other parameter I have used: "--update-catalog" dito manpage: "Update the message catalog index. This command needs to be executed each time new catalog files are installed, removed, or updated to rebuild the binary catalog index." I did a remove with my rm -rf command so the index is out of sync ! " --sync" dito manpage: "Asks the journal daemon to write all yet unwritten journal data to the backing file system and synchronize all journals" so all in all: ========= my journalctl commands or the parameter could be improved that's for sure. BUT, it works for me: it removes elder files ! you "@home user" are free to excute what I have provided on your questions. all what I provide is proofed and excuted by myself sometimes just BEFORE I put it on this list !!! Sure, it could be imperfect and sometime it is.

On 10/16/19 9:36 AM, sixpack13 wrote: I would not recommend that. systemd services use that space for temp files. You're likely to cause a problem with currently running services.

On 10/16/19 7:25 AM, home user wrote: Actually, none. Once the rpm is installed, there really is no real reason to keep them around. You can delete them all, especially the log files.  If you really want you can keep the last rpm file which matches your running kernel. -- The key to getting good answers is to ask good questions.

On 10/16/19 8:38 AM, home user wrote: It has nothing to do with dnf.  Potentially you could file a bugzilla with rpmfusion to ask for an enhancement to akmod-nvidia. However, the quickest/easiest solution is to create a cron job to cleanup the directory on a periodic basis. -- The key to getting good answers is to ask good questions.

On 10/16/19 11:58 AM, Tim via users wrote: Well, yes.  One could add a file in /etc/logrotate.d with the necessary info to do that. But since the log files are only useful when a compile fails and one (me?) would need to expend time thinking how to construct the /etc/logrotate.d file I'm inclined to take the lazy route.  :-) -- The key to getting good answers is to ask good questions.

(me) (Ed) (Tim) (Ed) (Ed) I patch my workstation weekly.  Almost all weeks, both the kernel and (a?)kmod-nvidia show up in the list of things being updated; very rarely does neither get updated.  So the akmod package for nVidia drivers is rebuilt on my system almost every week.  So it seems that I should submit a bug as suggested.  I assume no one has yet done that. What is the URL for the RFA/rpmfusion bugzilla?  (By the way, what does "RFE" stand for?) What I should request is that akmod-nvidia be enhanced to clean up after itself each time the akmod package is rebuilt, and suggest that the enhanced akmod-nvidia install an appropriate default /etc/logrotate.f file for that purpose? Have I got the naming and terminology correct?  Any other suggestions on wording this will be appreciated. thanks, Bill.

On 10/31/19 11:37 PM, home user wrote: Yes, make life easier on yourself and others.  I doubt anyone would spend any time on an RFE of this sort. So, just place this two line script in /etc/cron.weekly #!/usr/bin/bash find /var/cache/akmods/nvidia/ -type f -mtime +10 -exec rm -f {} \; It will simply delete all files older than 10 days.  You'll never have any collision.  You'll never have any space taken up of more than 24MB, which is tiny. -- The key to getting good answers is to ask good questions.

I'm having to put this aside until tomorrow afternoon.  I have personal business and commitments this evening and tomorrow morning; I'll do my weekly incremental back-up; scans, and patches tomorrow midday.  (another working lunch) Here's what's been accomplished so far: --------------- -bash.3[~]: cd / -bash.4[/]: df -hP Filesystem      Size  Used Avail Use% Mounted on devtmpfs        7.8G     0  7.8G   0% /dev tmpfs           7.9G   76M  7.8G   1% /dev/shm tmpfs           7.9G  1.7M  7.9G   1% /run tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup /dev/sda6        50G   31G   16G  67% / tmpfs           7.9G  116K  7.9G   1% /tmp /dev/sda3       477M  236M  213M  53% /boot /dev/sda7       904G  7.7G  851G   1% /home tmpfs           1.6G   72K  1.6G   1% /run/user/1001 tmpfs           1.6G  4.0K  1.6G   1% /run/user/0 -bash.5[/]: du -sh | grep G du: cannot access './run/user/1001/gvfs': Permission denied du: cannot access './proc/5742/task/5742/fd/4': No such file or directory du: cannot access './proc/5742/task/5742/fdinfo/4': No such file or directory du: cannot access './proc/5742/fd/3': No such file or directory du: cannot access './proc/5742/fdinfo/3': No such file or directory 39G    . -bash.6[/]: du -hx -d1 / 13G    /var 4.0K    /system-upgrade-root 4.0K    /srv 17G    /usr 16K    /lost+found 51M    /etc 4.0K    /sysroot 4.0K    /mnt 1.4G    /root 4.0K    /media 238M    /opt 4.0K    /.cache 31G    / -bash.7[/]: --------------- Good progress, but probably more to be done. I thank everyone for their help so far. Bill.

(responding to Joe) done. installation was easy. usage in root was mostly easy; between 40 and 50 MB recovered. Control over localizations was tedious.  Suggest either (better) a way to disable localization checks, or (not as good) a single check box equivalent to checking all the localizations to be retained.  I'll try to figure out localizations some other time. I have not yet tried this tool as a non-privileged Fedora user. I have not yet installed it on my windows-7 box. Next step outside of bleachbit is automating clean-up of stuff left behind by akmods when patching.  I'm researching this. thanks, Bill.

On 23/10/2019 21:36, Joe Zeff wrote: Recently I had disk-space problems when using mock on my F29 box. /var is 50 GiB but much of that was full of old files which I have now deleted. I've just looked at this, my main system box, running the el7 clone SL7.7, using konqueror file size view. Again /var is 50 GiB, of which 10.6 GiB is free. 27.4 GiB is occupied by /var/lib/yum/plugins/local, rpms dating from 2012 (Canon driver downloads) and others from 2014 to about a year ago when I disabled the local-repo plugin and yum stopped taking forever to do anything. Maybe I botched that installation. 7317 obsolete files... John P

I'm BA-A-A-a-a-ack! To answer Joe (about bleachbit), I did look at its wikipedia page quickly.  My impression is that it focuses on personal space (/home/...) rather than system space.  What was needed here was a huge amount system space.  I seriously doubt that bleachbit would have helped  to a serious degree.  It was a *quick* look, and I plan to come back to this, but for now, we're focused on recovering space where semi-annual upgrades need the space. I won't be doing another upgrade until mid spring, but I believe it wise to do the space recovery now, while this is fresh on the minds of thread participants.  I'll continue doing patches every week; I did one successfully with no problemsearlier this afternoon. Let's please tackle one directory sub-tree at a time. First, "/var/cache/abrt-di/usr/"... (Ed said) needed. (I responded) (Samuel then said) /var/cache should be deletable, case, if you don't have any anything under abrt-di. I've done a little more statistics on my "/var/cache/abrt-di/usr/". After doing "cd /var/cache/abrt-di/usr/", and running the appropriate commands I find it has: * 6035 sub-directories  ("tree -d --du > ~/abrtdi_tree.txt", then "view ~/abrtdi_tree.txt" and looking at the line count). * 11 levels below .../usr/. * 35759 'c' language source files  ("ls -alR | grep "\.c$" > ~/abrtdi_c.txt", then "view ~/abrtdi_c.txt" and looking at the line count). * 24369 'c' language ".h" header files  ("ls -alR | grep "\.h$" > ~/abrtdi_h.txt", then "view ~/abrtdi_h.txt" and looking at the line count). * 13827 links  ("ls -alR | grep "^l" > ~/abrtdi_l.txt", then "view ~/abrtdi_l.txt" and looking at the line count). I do not know if there are any core files in this sub-tree; I don't know what they would be named, so I don't know how to search for and count them.  The point is that what I do see in there does not look like what it was said to contain.  Is there something about my system's configuration that is wrong and I don't know it?  I hope you understand my concern and caution about deleting over 6000 directories containing over 40,000 source files!  Let's please be careful and sure about this!In case it helps, I fpasted "abrtdi_tree.txt" (output from "tree -d --du > ~/abrtdi_tree.txt") here: "https://paste.centos.org/view/94c5d039". Please hold off on discussion/suggestions about journal files and other things until we get this "/var/cache/abrt-di/usr/" done! thanks Bill.

(addressed to everyone) (responding to Joe) your system What are other list members' experiences with bleachbit run as root or a non-root admin. user?  Are the space gains worth the time and effort?  Has it caused problems by deleting things that shouldn't be deleted, or changing things inappropriately?  Is it easy to use?  I already have Firefox and Thunderbird set to clean out history, cookies, cache, etc..  I just finished setting up journald.conf to manage journald logs.  I'm about to start researching how to regularly clean out NVidia driver compile leftovers.  What of real significance is left for bleachbit to do? This does look good for my windows-7 box. thanks, Bill.

On 10/18/19 6:03 AM, home user wrote: Those are just files needed it a debug is to be done and a BZ to be submitted. As noted by Samuel, I too don't have that directory. Just delete it. -- The key to getting good answers is to ask good questions.

On 10/18/19 11:42 AM, home user wrote: The directory "/var/cache/abrt-di is created by the abrt-addon-ccpp. How/what/when the sub-directories are created I don't recall.  And, I'm not that curious to take the time to research it. However, those directories only contain information used for debug purposes.  They may be related to automatically reporting bugs.  So, the stuff in there is of no value at this point.  I wouldn't delete the directory but all the contents below it. You can check back in a month or so to see if new stuff has been placed there. I suggest you make a note of it.  I'm only responsible for reminding my cats not to wake me at 3AM. They ignore my request.  :-) -- The key to getting good answers is to ask good questions.

(responding to Samuel) https://bugzilla.redhat.com/show_bug.cgi?id=811978 Thank-you, Samuel.  I just added a comment to that bug saying that I too I experiencing problems, and referencing this thread.

(responding to Samuel) I looked at the redirected output from yesterday's "ls" commands, and saw lots of 2018 files, but no 2019 files.  But I don't think 2019 files would show up with " 2019 " in the "ls -al" output.  I also saw 2015 files, but no 2014 or 2013 files.  That is not an exhaustive search.  It seems that it's just all old junk that never got cleaned up, but I can't be certain. Wait, I just remembered "ls" has sort options. ls -aclR /var/cache/abrt-di/usr/ | grep "Oct 10" | more shows lots of hits; more recent dates show no hits.  So that directory sub-tree has stuff between the year 2015 and last Thursday inclusive. Bill.

On 10/18/19 12:40 PM, home user wrote: Where do they link to?

On 10/19/19 4:00 AM, Samuel Sieb wrote: From memory..... I recall they link places such as /usr/include and others which would be needed to properly generate a stack trace. -- The key to getting good answers is to ask good questions.

On 10/19/19 10:49 AM, home user wrote: You only want to delete the links.  You don't want to delete what the links are pointing to. The "rm" will only remove the links. Nothing under /var/cache/abrt-di is vital to the operation of the system. -- The key to getting good answers is to ask good questions.

On 10/18/19 9:14 PM, home user wrote: The grep is unnecessary here. You will only get the one line anyway (other than the errors). Also the result of this command is pretty much irrelevant anyway because it includes everything including /home. You can better numbers from the "df" output earlier. That bug is closed anyway.

"... until 'we' get this ..." ?! yup. I'm too searching for someone in "standby-mode" how is willing to manage my @live, esp. my bank account ! Benefit would be, if: - *I* could shift over the responsiblity for it if *I* messed something - he/she keeps an eye on it - let's say - 24/7 ;-) @home user, what you are smoking ? I'm A-W-A-Y !

On Sat, 2019-10-19 at 12:40 -0600, home user wrote: You mean journalctl: https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to... poc

On 10/20/19 9:45 AM, home user wrote: Well, the management and control of the journal is defined in journald.conf. So, how about reading "man journald.conf"? -- The key to getting good answers is to ask good questions.

On 10/20/19 8:32 PM, home user wrote: As soon as you restart journald, it will automatically clean the logs to fit the new settings. No gui, it's just a text file. Yes.

On Mon, 21 Oct 2019 at 00:32, home user <mattisonw(a)comcast.net&gt; wrote: My first question: The biggest log file messes I have seen came from some errant process dumping huge amounts of data into the logs in a matter of hours (Murphy's Law ssys this will usually occur over long weekends), so daily cleanups aren't adequate. Journald supports both rate limiting and size controls (free space and total space for journald files). Yes -- disks want to be full: the price of free space is eternal vigilance. -- George N. White III

On 10/22/19 9:50 AM, home user wrote: I would just make this observation.  But, first, I had not changed any defaults on my system and my journals had grown to their max 4GB.  It is now 3GB since I wanted to test some commands.  That being said.... My "work" system is up 24/7.  I run "dnf upgrade" whenever I feel like.  I reboot when new kernels are installed and when "tracer" indicates a reboot is reccommended after the upgrade. --list-boots shows 81 with the earliest being  2019-04-07 This tells me that if you're going to keep only 25 days of journal data you'll never come close to using the 3GB you're allocating.  So, it seems to me, you'll certainly meet your prime objective of having the journal use less disk space. -- The key to getting good answers is to ask good questions.

On 10/23/19 12:55 AM, home user wrote: Yes, of course, but that *wasn't* the point.  You listed how you use your system.  I was simply contrasting  my usage pattern and how much information is contained v.s. space taken As for individual preferences, I can't see how breaking up the journal into 25 files with each holding 1 day of information has any advantage.  The journal files are not text files but journald specific "database" files.  So, splitting up this way doesn't make it easier to locate information for a given day, IMO. -- The key to getting good answers is to ask good questions.

The thing I'm now trying to do is automate the cleaning out of things left behind by akmod(?) after the weekly patch (dnf upgrade).  A cron job seems like the most natural way to do this.  Since the patches are weekly, I believe the cron job should be weekly, scheduled for a day and time when the workstation is almost always up, but idling. Here is my current /var/cache/akmods/nvidia/ directory: ----- -bash.29[nvidia]: ls -la total 60628 drwxr-xr-x. 2 root   root      57344 Oct 24 11:01 . drwxr-xr-x. 3 akmods akmods     4096 May 15 18:42 .. -rw-r--r--. 1 root   root     535759 Oct 17 14:06 430.40-1-for-5.3.5-200.fc30.x86_64.log -rw-r--r--. 2 root   root     535714 Oct 24 11:01 430.40-1-for-5.3.6-200.fc30.x86_64.log -rw-r--r--. 1 root   root   12081124 Oct  3 11:54 kmod-nvidia-5.2.17-100.fc29.x86_64-430.40-1.fc29.x86_64.rpm -rw-r--r--. 1 root   root   12081040 Oct 10 10:11 kmod-nvidia-5.2.18-100.fc29.x86_64-430.40-1.fc29.x86_64.rpm -rw-r--r--. 1 root   root   12081932 Oct 10 15:31 kmod-nvidia-5.2.18-200.fc30.x86_64-430.40-1.fc30.x86_64.rpm -rw-r--r--. 1 root   root   12078996 Oct 17 14:06 kmod-nvidia-5.3.5-200.fc30.x86_64-430.40-1.fc30.x86_64.rpm -rw-r--r--. 1 root   root   12078980 Oct 24 11:01 kmod-nvidia-5.3.6-200.fc30.x86_64-430.40-1.fc30.x86_64.rpm -rw-r--r--. 2 root   root     535714 Oct 24 11:01 .last.log -bash.30[nvidia]: ----- I have a few questions: * Best practice is to have the job run as which user? * I gather from the man pages for cron and crontab that there are multiple crontabs.  Best practice for this is to use which one? * Is the command "rm -rf /var/cache/akmods/nvidia/*" good, overkill, or not enough" * Is best practice to edit the appropriate crontab with my favorite editor, or is there a specific tool or command that I should use? Anything else I should know before I do this? thanks, Bill.

(responding to Ed) done. The script looks like this: ----- #!/usr/bin/sh # clean out files left behind by the compiling that follows patching or # updating the kernel and/or the driver for the nvidia graphics card. rm -rf /var/cache/akmods/nvidia/* exit $? # done! ----- That I may better understand... Am I correct in assuming which shell I use does not matter in this case? What is the difference between "/usr/bin/sh" and "/bin/sh"? What day of the week will this be run? What is the significance of the "98-" at the beginning of the file name? /var/cache/akmods/nvidia/ was one of the things I cleaned out earlier in this thread (or this thread's parent), but I can't find how much space that freed.  But I vaguely recall it being a lot. 1GB divided by 12.5MB = 80 new kernels. Once the script above has run, I will check on /var space again and post results.  I think the major things have been cleaned out, and whatever junk is left is, as a few list members have said, not worth the trouble. thanks, Bill.

On 10/25/19 7:56 PM, home user wrote: This line is redundant. The exit code of the script is the one from the last command executed. /bin is a symlink to /usr/bin so those are the same file.

As of mid-day Saturday, Oct. 26, here is what '/' filesystem space use looks like on this work station: =============== bash.2[/]: df -hP Filesystem      Size  Used Avail Use% Mounted on tmpfs           7.8G  1.7M  7.8G   1% /run /dev/sda6        50G   24G   23G  52% / /dev/sda7       904G  7.6G  851G   1% /home /dev/sda3       477M  237M  211M  53% /boot [6 others, each using < 1M] ----- bash.3[/]: du -hx -d1 / 6.1G    /var 17G     /usr 51M     /etc 1.4G    /root 238M    /opt [7 others, each using < 1M] 24G     / bash.4[/]: ----- bash.7[/]: du -hx -d1 /var 3.7G    /var/cache 847M    /var/spool 565M    /var/lib 1.1G    /var/log [16 others, each using < 1M] 6.1G    /var bash.8[/]: ----- bash.8[/]: du -hx -d1 /var/cache 8.0K    /var/cache/abrt-di   (left in to show results) 144M    /var/cache/PackageKit 44M     /var/cache/cups 2.9G    /var/cache/system-upgrade 6.7M    /var/cache/man 501M    /var/cache/dnf 60M     /var/cache/akmods 2.2M    /var/cache/app-info [15 others, each using < 1M] 3.7G    /var/cache bash.9[/]: ----- bash.9[/]: du -hx -d1 /var/log 1.8M    /var/log/anaconda 2.8M    /var/log/ConsoleKit 873M    /var/log/journal 1.2M    /var/log/gdm 20M     /var/log/rkhunter 40M     /var/log/audit 9.7M    /var/log/upgrade.journal 2.3M    /var/log/boot-sav [17 others, each using < 1M] 1.1G    /var/log bash.10[/]: ----- Question 1: /var/cache/system-upgrade/updates/packages/ takes up 1.6G and appears to be full of rpm's (1083 of them), each dated 2015 (various months).  I do not know the fine details of dnf and rpm.  Can I safely delete them, or might that break future patching and upgrading, and other dnf/rmp commands? Question 2: /var/log/ has 193 files that are not sub-directories, and are not stored in sub-directories.  134 are from prior years. Curious: all 134 are from 2016 or earlier; this directory has no files from 2017 or 2018.  The files called "messages-[date]" are huge: each over 10M.  Can I delete files older than this year safely, or are they needed for something? Question 3: /var/log/rkhunter/ has 184 files, most are from prior years.  Am I correct in assuming that I can delete the files from prior years? Question 4: Is there already available some automated deletion of /var/log/ logs (and its sub-directories other than "journal")? Question 5: Are there any other parts of the '/' filesystem that I should clean out and are worth the trouble? thanks, Bill.

On 10/27/19 2:49 AM, home user wrote: That entire directory can be deleted.  It was used by fedup, the forerunner to "dnf system-upgrade". No longer used, no longer needed. Old log files aren't used and can be discarded. Yes. Yes.  You should see.... systemctl status logrotate.timer   as active (waiting) The control over what is rotated is determined by entries in /etc/logrotate.d Not as far as I'm concerned. -- The key to getting good answers is to ask good questions.

On 10/27/19 8:43 AM, home user wrote: Why?  I said the *entire* /var/cache/system-upgrade/ directory can be deleted. I said it is no longer used. rm -rf /var/cache/system-upgrade/ There should be no question. General answer Google is your friend. Just Google "delete files by age linux" -- The key to getting good answers is to ask good questions.

Good afternoon, everyone. After wrestling this for 17 days, here's where things stand: --------------- -bash.9[~]: du -hx -d1 / 5.4G    /var 4.0K    /system-upgrade-root 4.0K    /srv 17G    /usr 16K    /lost+found 51M    /etc 4.0K    /sysroot 4.0K    /mnt 1.4G    /root 4.0K    /media 238M    /opt 4.0K    /.cache 24G    / -bash.10[~]: df -hP Filesystem      Size  Used Avail Use% Mounted on devtmpfs        7.8G     0  7.8G   0% /dev tmpfs           7.8G   89M  7.8G   2% /dev/shm tmpfs           7.8G  1.7M  7.8G   1% /run tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup /dev/sda6        50G   24G   24G  50% / tmpfs           7.8G   84K  7.8G   1% /tmp /dev/sda7       904G  7.3G  851G   1% /home /dev/sda3       477M  237M  211M  53% /boot tmpfs           1.6G   68K  1.6G   1% /run/user/1001 -bash.11[~]: --------------- A lot of no-longer-needed files have been deleted. A lot of valuable space has been recovered. A lot has been learned. I did not try everything; I did not respond to every post, but it was impractical to do so.  The efforts to help were appreciated. There are more unneeded files in the '/' filesystem (and elsewheres), but it does not add up to enough space to justify the time and effort. Ed: * I did research the other logs in /etc/, and the management of them, but decided they were too small to further pursue.  The few long log files are auto-deleted anyway. * I did not forget your suggestion of re-partitioning to shift space from /home and using that for a new /var partition. Currently, I don't think any media I have has space for /home. And doing the re-partitioning would take more help from this list than this thread did. I'm marking this thread SOLVED.  I thank all participants for their help, patience, and understanding. Bill.