Debian's /tmpest in a teapot [LWN subscriber-only content]

Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net! Free trial subscription Try LWN for free for 1 month: no payment or credit card required. Activate your trial subscription now and see why thousands of readers subscribe to LWN.net.

Debian had a major discussion about mounting /tmp as a RAM-based tmpfs in 2012 but inertia won out in the end. Debian systems have continued to store temporary files on disk by default. Until now. A mere 12 years later, the project will be switching to a RAM-based /tmp in the Debian 13 ("Trixie") release. Additionally, starting with Trixie, the default will be to periodically clean up temporary files automatically in /tmp and /var/tmp . Naturally, it involved a lengthy discussion first.

Join the party

By now, using tmpfs for the /tmp directory is a road well-traveled. Many Linux distributions have already switched to mounting /tmp as a tmpfs. Arch Linux, Fedora, openSUSE Tumbleweed, and many others have all made the switch. Red Hat Enterprise Linux (RHEL) and its clones, as well as SUSE Linux Enterprise Server (SLES) and openSUSE Leap, still default to /tmp on disk. Ubuntu, following Debian, also continues to have a disk-based /tmp rather than using tmpfs.

The knobs to control how /tmp is mounted, and the handling of temporary files, are part of systemd. (On systems where systemd is used, of course.) The upstream defaults for systemd are to mount /tmp as a tmpfs and delete files that have not been read or changed after ten days in /tmp and 30 days for those stored in /var/tmp . Debian Developer and systemd contributor Luca Boccassi recently decided it was time to revisit the topic of /tmp as a tmpfs, and start deleting temporary files in /tmp and /var/tmp .

On May 6 Boccassi resurrected a discussion from Debian's bug tracker that started in 2020 and that had trailed off in July 2022 without resolution. The bug was submitted by Eric Desrochers, who complained that Debian's systemd implementation did not clean /var/tmp by default. Michael Biebl wrote that this was a deliberate choice to match Debian's pre-systemd behavior. After a long period of inactivity, Biebl suggested in October 2021 (and again in July 2022) that Desrochers raise the topic on the Debian devel mailing list. That never happened.

In reviving the topic, Boccassi declared that it was time to bring Debian's defaults in line with upstream and other Linux distributions by making /tmp a tmpfs, and cleaning up /tmp and /var/tmp on a timer. He planned to apply those changes in the next systemd upload to Debian unstable within a week, with instructions in the NEWS file on how to override the changes for any users who wanted to keep the current behavior. That, in turn, sparked quite a discussion.

The case for and against

Biebl worried about the effect of cleaning up temporary files by default. Currently, he said, Debian only cleans /tmp on boot (which is unnecessary if /tmp is a RAM-based tmpfs) and to never clean up files in /var/tmp . Boccassi answered: " Defaults are defaults, they are trivially and fully overridable where needed if needed. " Biebl replied that there is value in aligning defaults across Linux distributions, but argued that Debian has " a larger scope " than a desktop distribution like Fedora. He suggested that it was necessary to " gather feedback from all affected parties to make an informed decision ". Boccassi responded that it was impossible to have defaults that would make everyone happy, and he was not looking for hypothetical arguments or philosophical discussions, he wanted facts: " what would break where, and how to fix it? "

Sam Hartman noted that ssh-agent created its socket under /tmp , but it would be better if it respected the $XDG_RUNTIME_DIR setting and created its socket under /run/user . Boccassi agreed and said that he had filed a bug for ssh-agent . Richard Lewis pointed out that tmux stores its sockets in /tmp/tmux-$UID , and deleting those files might mean users could not reattach to a tmux session that had been idle a long time. Boccassi suggested that using flock() would be the right solution to stop the deletion, and said he had filed a bug on that as well.

Lewis questioned whether files downloaded with apt source might be considered "old" when they were extracted under /tmp and immediately flagged to be deleted. Russ Allbery said that systemd-tmpfiles would respect the access timestamp (atime) and changed timestamp (ctime), not just the modified timestamp (mtime), " so I think this would only be a problem on file systems that didn't support those attributes ". Allbery said he believed tmpfs supports all three.

Some users store information in /var/tmp for long-running jobs, because they want it preserved without being backed up, said Barak A. Pearlmutter. Boccassi dismissed that, saying that those users " assuming they actually exist ", can customize the system defaults according to their needs.

Those users do exist, wrote Jonathan Dowland, " [I've] been one of them, I've worked with many of them, it's an incredibly common pattern in academic computing ". Making a change to how these files are handled, " should be a very carefully explored decision ". He also asked for arguments in favor of the change, and to hold off the change to allow the discussion to continue.

Hartman wished that it was possible to specify that directories under /var/tmp should be deleted entirely or left alone. Boccassi said that was a reasonable enhancement request, and that it had already been filed upstream for systemd.

Allbery eventually admitted surprise at the number of people who reported using /var/tmp " for things that are clearly not temporary files in the traditional UNIX sense ". Periodically deleting files in /var/tmp , he said, has been common UNIX practice for at least 30 years:

Whatever we do with /var/tmp retention, I beg people to stop using /var/tmp for data you're keeping for longer than a few days and care about losing. That's not what it's for, and you *will* be bitten by this someday, somewhere, because even with existing Debian configuration many people run tmpreaper or similar programs. If you are running a long-running task that produces data that you care about, make a directory for it to use, whether in your home directory, /opt, /srv, whatever.

Hakan Bayındır said that he did not use /var/tmp , but applications that other people use do. He cited a high-end scientific application that was not under his or other users' control. Allbery argued that this was " not a good design decision " but conceded that may not be helpful if a user or admin does not have control over the application's design. However, he said, it was " playing with fire " to use /var/tmp that way " and it's going to result in someone getting their data deleted at some point, regardless of what Debian does ".

Lewis said he still did not understand the rationale for the change. Was there, he asked, " perhaps something more compelling than 'other distributions and upstream already do this'? " That sounded like the original rationale, Allbery said, but he added that moving /tmp to tmpfs should make applications run faster, and reaping files under /var/tmp could help to avoid filling up a partition. Allowing the partition to fill up, he noted, could cause bounced mail, unstable services, and other problems. It may not be a problem for desktop systems, which tend to have enough disk space not to be affected, but for virtual machines that have /var/tmp contained within a small root partition, it is still a concern.

Rolling out changes

In the end, none of the arguments for maintaining Debian's status quo managed to persuade Boccassi to stay his hand. On May 28, Boccassi announced the changes that he had made and uploaded to unstable. As expected, /tmp will become a tmpfs by default, for both new and existing installations. New installs will use the systemd default behavior. The openssh and tmux packages, he said, had been fixed to provide exceptions to retain their temporary files. A description has been added to the Debian installer to inform users that /tmp is a tmpfs by default, and the changes have been noted in the NEWS file. He also offered to review and merge any changes to the Debian installer that would let users customize those options during installation. Users who want /tmp to remain on disk can override the upstream default with systemctl mask tmp.mount . To stop periodic cleanups of /tmp and /var/tmp users can run touch /etc/tmpfiles.d/tmp.conf .

None of the changes, it should be noted, will affect Debian versions prior to Trixie. Users of Debian stable and oldstable will only encounter these changes on upgrade.

As noted, many distributions have already made these changes without catastrophe. Debian, and its users, should be able to adapt to the new defaults or override them if they are unsuitable for the workloads to be run. At worst, it promises to be a temporary inconvenience.