Well-used computers rapidly acquire many files in the depths of the system that you no longer need; additionally, the system accumulates duplicate and multiply stored data. Manually searching for duplicates, temporary files, or orphaned files can be extremely difficult in view of the several hundred thousand files that most popular Linux distributions keep in their storage systems. Armed with a couple of helpers, however, you can quickly deal with any unnecessary clutter and keep your system permanently clean.

Analysis

The starting point of any cleaning action is careful analysis of the data sets. A tool that is particularly suitable for this is a small Java program named JDiskReport that elicits all the necessary information from your hard disk. The program is available as a ZIP archive [1]; just unpack and move the newly created JDiskReport-1.4.1 directory to a suitable place (e.g., /opt). You can then start the software by calling

java -jar /opt/jdiskreport-1.4.1.jar

The application asks you which file tree you want to edit, scanning this choice first. JDiskReport lists all the system's users, and you can select one by clicking. JDiskReport then displays storage space usage in a pie chart (Figure 1).

Figure 1: Meaningful charts show storage space consumption.

JDiskReport offers a few options that you mostly access from the horizontal tab bar in the program window. For an overview of the main disk hogs, check out the Top 50 tab. On many current distributions, you will see files of a considerable size that reside below /var/log/journal/<UUID>. These are the systemd logfiles, which are not regularly cleared by default.

To discover the precise size of these logfiles, open a terminal and type the following command as root:

journalctl --disk-usage

The total volume of archived logfiles can be several gigabytes depending on the capacity of the active partition. Because the system creates new files regularly, you can easily delete old systemd logs. To prevent the uncontrolled growth of systemd logs, you can set the SystemMaxUse= parameter in the /etc/systemd/journald.conf file to a reasonable value (e.g., SystemMaxUse=100M for maximum system log size of 100MB).

After scanning the entire file tree from the root directory, you might want to take a closer look at individual directories; to do so, just click in the pie chart on the segment to be examined. JDiskReport now displays all the subdirectories in a new pie chart. The Top 50 items also change accordingly.

Unfortunately, JDiskReport cannot delete files from the individual lists. Using a file manager or the command line, however, you can manually remove duplicates or unnecessary log files.

Leftovers

Most application programs create temporary, session-specific files that are no longer needed. Additionally, desktop environments create various history files in which they store the most recently opened documents or thumbnails. You can thus quickly accumulate a few hundred megabytes of obsolete data.

In KDE SC, the Sweeper tool, which you can find in the repositories of all major distributions, eliminates these "dead files." When launched, Sweeper shows you a dozen deletion options, all of which are checked and thus enabled. A click on the Clean Up switch deletes the corresponding files and directories (Figure 2).

Figure 2: Sweeper primarily purges history storage on KDE systems.

Sweeper has relatively few options available for mastering the flood of obsolete files. Therefore, the additional use of a tool that can perform delete actions for many locally installed applications in a program-specific way is also recommended. In this case, BleachBit should be your first port of call. You can find it in the repositories of all major distributions, and the project website also offers the source code [2].

BleachBit starts in a two-panel program window; on the left, it shows various options, sorted by installed program. On the right, you see more information on each option. By checking or unchecking boxes in the Active column, you can adjust the functionality to suit your needs.

If you instruct BleachBit to overwrite areas of free space completely after removing existing data residue, the program can take some time to complete the action. Remember that overwriting on flash-based storage makes little sense, because, on the one hand, current SSD controllers organize the storage content themselves and, on the other, more writes just increase the wear on the medium, especially on low-budget SSDs and SD memory cards.

After enabling the options you want, start to remove files by clicking on the Clean button. After it's done, BleachBit shows you the deleted files individually and provides a brief summary. You will usually see an error message in the last line: It indicates that BleachBit did not delete a certain number of files because of lack of rights (Figure 3).

Figure 3: BleachBit does not delete all the unnecessary files in user mode.

To delete all files, you must launch BleachBit with root privileges. For this reason, you will usually find two boot entries in the Tools menu after the install. Although the conventional version of BleachBit works with normal user rights, the BleachBit (root) entry enables the software with universal rights for deleting, for example, logfiles created by system daemons.

If you use applications for which BleachBit has no cleaning routines, then you can write your own cleaning instructions. The tool supports application-specific routines in the /usr/share/bleachbit/cleaners/ directory and user-specific routines in ~/.config/bleachbit/cleaners/. Depending on the application, you can create your own CleanerML files in a text editor in these directories and integrate them seamlessly into BleachBit. For the structure and syntax of the CleanerML files, refer to the corresponding tutorial [3].

Beyond this, BleachBit also has a repository [4] that offers more routines that are not (yet) part of the standard application scope. You can integrate these into your system by downloading the relevant XML file and moving it into the active cleaners directory. When next started, BleachBit automatically takes the new cleaner into account.

Orphans

When you uninstall applications, orphaned files are often left behind. These are frequently application-specific libraries that were set up as dependencies but are now obsolete. If you often try out new software and then delete it again, you can quickly accumulate many orphaned files.

To locate these unnecessary data files and delete them, DEB- and RPM-based distributions offer powerful command-line tools: deborphan and rpmorphan. Designed for use on Debian and Ubuntu and its offshoots, the deborphan command is available with an optionally installable graphical interface, GtkOrphan. On Fedora, openSUSE, Mandriva, Mageia, Pink, and other RPM-based operating systems, the rpmorphan command offers the -gui parameter for an optional graphical interface (Figure 4). You can browse the files listed in the GUI, select them with your mouse, and then press Remove to delete them from the system.

Figure 4: Simple and without any unnecessary frills: the rpmorphan GUI.

On distributions that use the User RPM (URPM) package management, you can delete orphaned files using the urpme --auto-orphans command. A word of caution: urpme occasionally displays erroneous information, primarily after updates. Although rpmorphan on our lab computer with the 64-bit version of Mageia 3 discovered 12 orphaned files, urpme wanted to delete no fewer than 76 allegedly orphaned files (Figure 5).

Figure 5: Users beware: urpme is little too eager to delete files!

After removing the files classified by urpme as superfluous, our lab system had no file manager, and playback options for multimedia content were very limited. On another test system with openSUSE 13.1, rpmorphan suggested deleting several key program components of LibreOffice as "orphaned" files. Therefore, I highly recommend that you examine the proposed remove lists closely and leave any alleged orphaned files in place on the system if in doubt.