Dear all,
Hereby a little cleaning script I wrote .. It's completely safe (use it already a long time with no problems), feel free to copy and use ...
Don't forget to install the Trash-cli utility to make use of all the features of the script ... Have fun ! By the way, sorry folks, but I use Bash and not Dash !
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason:Topic automatically closed 6 months after creation. New replies are no longer allowed.
Just a note: you can delete everything in ~/.cache no need for separate lines - so rm -rf ~/.cache/* will do the job. Also /tmp is cleaned on reboot, so no real need to worry about it. More importantly; why would you want this sudo rm -r -v -f /var/log/*? You'd be deleting all of your log files!
I'll let others comment on the rest of the script.
In addition to chrisuk: for deleting log files, or rather restricting their size, it's better to use logrotate. Sometimes you need a log for debugging.
Furthermore, it's advisable to use purge-old-kernels (part of the byobu set) for deleting old kernels, because it'll leave one spare older kernel. You should always have one older, tried and tested kernel in reserve.
In general, I don't like such scripts. Demolition should be done carefully, step by step, and scripted cleaning is too much like a wrecking ball....
I would agree with the log thing. No way I would ever delete all those logs like that. Logs are key if you're compromised or trying to troubleshoot, as mentioned. Once logs get to a certain size, you could make them .bak then crawl them now and then to delete outdated logs.
However, at least IMO, it's not needed. You could just compress older logs -- since it's only plain text, compression does wonders. I have a log consisting of over 6200 lines which takes up only 392K, and that's not compressed. With gzip, it's down to a mere 32K.
I can imagine a situation when clearing /tmp could be useful: if it's an always-on machine, or oft-on.
BUG: Error on line 84, though: "trash-empty" is not found. Was it supposed to point to a now-removed function?
BUG: There's also an error where it's looking for a user directory "mint", when you need $USER or use $HOME for /home/$USER.
BUG: Error on line 1 too; the shebang should read:#!/bin/bash
There were two points brought out in comments by another user:
Pjotr
Don't use old scripts without research: much has changed since 2011/2012. Some objections to this script:
It removes kernels. You should only remove kernels by means of the kernel tool in Update Manager (a tool that wasn't around five years ago, when this script was created).
It uses aptitude. Don't mix the use of aptitude and apt-get. They probably use different databases, so they might come to different conclusions about what's safe to delete and what not. You've already used apt-get when using Synaptic and Update Manager....
Can you address these concerns and modify the script appropriately, assuming that Pjotr is correct in his assertions?
I advise to treat the tutorials in the community section with as much caution as any other how-to. They aren't being checked for quality and are often simply outdated....
Pjotr wrote: ⤴Wed Mar 14, 2018 1:06 pm
I advise to treat the tutorials in the community section with as much caution as any other how-to. They aren't being checked for quality and are often simply outdated....
That was what I gathered from your comment in the community section. The script that is given in this thread appears to be similar to the one you commented on, so I assume the same points you raise there are applicable here.
I would appreciate your guidance in modifying the script to address these issues, replacing the aptitude calls with the equivalent apt-get calls and utilizing the update manager to address the kernels.
...for the record, sudo rm -r -v -f /var/log/* should never be used...it can lead to various problems (folders residing there should NOT be deleted). So...
Pjotr wrote: ⤴Sun Aug 06, 2017 4:48 amDemolition should be done carefully, step by step, and scripted cleaning is too much like a wrecking ball...
I must concur that it makes more sense to approch this in pieces as opposed to scripted, although it would be a good idea to simply list the various safe steps that can be taken to clean up a root partition that is getting space warnings.
After looking at the man page I decided to run:
sudo apt-get clean
This freed up a bit over 3G on the root partition, so that is probably sufficient at this time. Looking at my /boot directory I see less than 500M in use, so even were I to eliminate a number of the older kernels there the savings are not even close to that obtained by cleaning with apt-get.
Yeah, when I do some cleaning, I just run the above mentioned command, hsh (alias: https://github.com/terminalforlife/bash ... liases#L88), and whenever I remove packages, I have them autoremove-ing (alias: https://github.com/terminalforlife/bash ... liases#L62) as well (plus purged). I also tend to use roks (https://github.com/terminalforlife/roks) to ensure I only have one kernel installed and in use, although I wouldn't recommend that for someone not at least a fair bit experienced with Linux. By default, /tmp gets blasted away during a reboot, so I don't need to do anything with that, and it's a 4GB tmpfs (RAM Disk, essentially) anyway.
small heads up in XFCE Desktop using this script. .cache/sessions/xfce4-session-YOU:0 gives errors in .xsession-errors if deleted. i usually delete everything in .cache and if i mistakenly delete .cache/sessions/xfce4-session-YOU:0 i create a blank text and name xfce4-session-YOU:0 <<< YOU is the hostname