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:

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.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.