1. Introduction
The Linux /tmp directory can store any number of files for the correct operation of the operating system (OS) and its applications. These can vary from system to system and be composed of privileged and non-privileged application data.
In this tutorial, we explore the consequences of deleting the temporary directory contents and ways to do that relatively safely. First, we briefly touch on the subject of temporary directories. Next, we discuss the potential consequences of non-selective file deletion. Finally, we go through safe temporary file removal methods.
We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments.
2. Temporary Directory
Temporary directories are operating system constructs for storing data that shouldn’t exist on the system permanently:
- lock and PID files
- UNIX sockets
- logs
- scratch and buffers
- non-permanent file backups
- package system data
- custom data
This vague definition includes files that may exist until a reboot, which may be a very long time, especially for servers. While some of these file types have their own directories like /var/log, /var/lock, and similar, they are usually only accessible to services and superusers.
On the other hand, all users commonly have access to a temporary directory, although permissions still apply as usual between them.
In Linux, the temporary directory is at /tmp. Further, due to its special function, it often resides on a separate partition.
While we can move /tmp to a different partition, clearing its contents indiscriminately is a bad and strongly discouraged practice.
3. Ramifications of Deleting Temporary Files
The potential consequences of removing temporary files are the same as deleting any other piece of data. They depend on the file function, contents, and current users.
Let’s explore the general idea with some common cases.
3.1. Locks
Of course, deleting a lock file breaks the single instance mechanism. This can result in multiple issues:
- concurrency problems
- resource wasting
- unexpected behavior
- errors when launching instances
In short, stability can be compromised depending on the nature, owner, and specific purpose of the lock.
3.2. Sockets
Sockets are used for inter-process communication (IPC) between processes in a Linux system.
For example, mysql has the –socket switch for specifying a MySQL socket. The latter can be and often is within the /tmp directory.
Removing that prevents connections to MySQL via the socket until it’s re-established. When and how that happens, as well as detecting the root cause, can be complex for any socket.
3.3. Logs
Since they are the records for a system and its applications, losing logs might leave us unable to perform basic analyses like troubleshooting, tracking, auditing, and forensics. This can be even more important when it comes to security-critical environments.
Normally, logs reside in special directories outside of danger from regular users. Still, some applications store such data in /tmp, exposing it to possible wipes by reckless administrative activity.
3.4. Package Data
Often, package managers use /tmp as a scratch and buffer area when downloading data.
For example, like most, Debian systems require a local package for installation, even if it’s just for a while. Thus, accidentally removing this temporary local file before it has served its purpose can result in an error.
3.5. Application-Critical Data
Depending on the type of software, different files can be stored in /tmp that, if they go missing, can degrade or destabilize the system. We highlighted some common instances, but custom solutions can lead to custom problems.
So, what can we do about these?
4. Safely Clear /tmp
We can always use standard tools for attempting to remove all temporary files:
$ rm -rf /tmp/*
However, to avoid potential issues, we can use standard and safer ways to clear /tmp.
Let’s explore some of them.
4.1. Policies
Of course, management requires policy. In this case, to safely delete temporary files, we need to be able to answer several questions about application data stored in /tmp:
- which applications use /tmp
- which applications delete their own data when it’s no longer relevant
- what data is being stored and not deleted
- when does each piece of information become irrelevant
Naturally, these are potentially difficult to know. Regardless, knowing how to handle each file is paramount.
4.2. Checks
First, we check which process uses every file. At the same time, we can confirm ownership and permissions. This way, we can map the data. As far as filenames go, software commonly adds a non-random component to generated names, as we can see with an ls listing:
$ ls /tmp
ssh-Fk1mc0z8126c
ssh-l27nXzy2X066
systemd-private-cb48066603cfeee3b80d77a871d1c3fb-systemd-logind.service-zxFdee
systemd-private-cb48066603cfeee3b80d77a871d1c3fb-systemd-timesyncd.service-lmzckj
tmux-0
In any case, we can script owning process, user, and group checks, so names may not be as relevant.
To know whether files get deleted by the associated application, we can often just close the application. Still, doing the latter the normal way is only the initial step. Next, checking how sudden termination affects self-clean-ups is also important.
After getting a map of applications to files and knowing what data we don’t need to take care of, we should see how and when to handle the rest. The analysis is done on a per-case basis, but file type and age often matter.
For example, we might need to -delete all [-f]iles that haven’t been accessed (-atime) for at least four weeks (28 days):
$ find /tmp -type f -atime 28 -delete
Here, we enforce this via find. To perform this at given intervals, we can employ a standard UNIX mechanism.
4.3. Using cron
As with most tasks, cron can perform the checks we discussed on a regular basis. However, this usually necessitates the writing of a script and configuring its execution and scheduling.
On the other hand, there is a specialized service that comes with some init systems.
4.4. systemd-tmpfiles Service
While it doesn’t cover all points, systemd-tmpfiles can handle temporary file deletion based on prespecified criteria:
- path
- permissions (mode)
- owning user and group
- age
In any case, this information should be available beforehand.
5. Summary
In this article, we talked about removing files from the /tmp directory.
In conclusion, while there are different ways to ensure the safe deletion of temporary data, we need to understand the consequences and analyze the data before attempting to leverage a given method.