LWN：Debian切换 /tmp 引来的讨论！

关注了就能看到更多这么棒的文章哦～

Debian's /tmpest in a teapot

By Joe Brockmeier
June 3, 2024
Gemini-1.5-flash translation
https://lwn.net/Articles/975565/

Debian 在 2012 年进行了一场关于将 /tmp 作为 RAM-based tmpfs 挂载的重大讨论 (讨论), 但最终惯性占了上风。Debian 系统默认情况下继续将临时文件存储在磁盘上。直到现在。仅仅 12 年后，该项目将在 Debian 13 ("Trixie") 版本中切换到 RAM-based /tmp 。此外，从 Trixie 开始，默认情况下将定期自动清理 /tmp 和 /var/tmp 中的临时文件。当然，这首先需要经过长时间的讨论。

加入派对

到目前为止，将 tmpfs 用于 /tmp 目录已是一条被广泛接受的道路。许多 Linux 发行版已经切换到将 /tmp 作为 tmpfs 挂载。Arch Linux、Fedora、openSUSE Tumbleweed 和许多其他发行版都进行了切换。Red Hat Enterprise Linux (RHEL) 及其克隆，以及 SUSE Linux Enterprise Server (SLES) 和 openSUSE Leap，仍然默认将 /tmp 存储在磁盘上。Ubuntu 遵循 Debian，也继续使用基于磁盘的 /tmp ，而不是使用 tmpfs。

控制 /tmp 挂载方式和临时文件处理方式的设置开关是 systemd 的一部分（当然，在使用 systemd 的系统上。）systemd 的上游默认设置是将 /tmp 作为 tmpfs 挂载，并在 /tmp 中删除未在 10 天内读取或更改的文件，并在 /var/tmp 中删除未在 30 天内读取或更改的文件。Debian 开发者和 systemd 贡献者 Luca Boccassi 最近决定是时候重新审视将 /tmp 作为 tmpfs 的话题，以及讨论是否开始删除 /tmp 和 /var/tmp 中的临时文件了。

5 月 6 日，Boccassi 复活了 Debian 的错误追踪系统中的一段讨论，该讨论始于 2020 年，并在 2022 年 7 月没有达成共识的情况下逐渐消失。该错误是由 Eric Desrochers 提交的，他 抱怨 Debian 的 systemd 实现在默认情况下不清理 /var/tmp 。Michael Biebl 写道：这是一个故意选择，是为了匹配 Debian 在 systemd 之前的行为。在长时间的停滞之后，Biebl 建议 在 2021 年 10 月（以及 再次 于 2022 年 7 月提出）Desrochers 在 Debian devel 邮件列表中提出这个话题。这件事从未发生。

在重新提起这个话题时，Boccassi 宣称，是时候将 Debian 的默认设置与上游和其他 Linux 发行版保持一致了，方法是将 /tmp 设为 tmpfs，并使用 timer 定时清理 /tmp 和 /var/tmp 。他计划在未来一周内将这些更改应用到下一个上传到 Debian 不稳定版本的 systemd 中，并在 NEWS 文件中提供说明，说明如何为任何希望保留当前行为的用户来把这些更改覆盖掉。这反过来引发了一场相当激烈的讨论。

赞成和反对的理由

Biebl 担心 默认情况下清理临时文件的影响。他说，目前，Debian 仅在启动时清理 /tmp （如果 /tmp 是一个 RAM-based tmpfs，则没有必要），并且永远不会清理 /var/tmp 中的文件。Boccassi 回答：“默认值是默认值，它们在需要时可以很容易地完全覆盖。” Biebl 回答 说，在 Linux 发行版之间统一默认值是有价值的，但他认为 Debian 的““范围更大””比 Fedora 这样的桌面发行版。他建议有必要““收集所有受影响方的反馈以做出明智的决定”。 Boccassi 回应 说，不可能制定出让每个人都满意的默认值，他不希望进行假设性的争论或哲学上的讨论，他想要事实：“哪些地方会失效，以及如何修复？”

Sam Hartman 注意到 ssh-agent 在 /tmp 下创建了它的套接字，但如果它尊重 $XDG_RUNTIME_DIR 设置并在 /run/user 下创建它的套接字会更好。Boccassi 同意 并说他已经针对 ssh-agent 提交了一个bug 。Richard Lewis 指出 tmux 将其套接字存储在 /tmp/tmux-$UID 中，删除这些文件可能意味着用户无法重新连接到长时间处于空闲状态的 tmux 会话。Boccassi 建议 使用 flock() 将是阻止删除的正确解决方案，并 说 他已经 提交了一个错误 关于这件事。

Lewis 质疑 是否使用 apt source 下载的文件在 /tmp 下解压缩并立即标记为要删除时可能被认为是“旧”的。Russ Allbery 说 systemd-tmpfiles 将尊重访问时间戳 (atime) 和更改时间戳 (ctime)，而不仅仅是修改时间戳 (mtime)，“所以我认为这只会成为文件系统不支持这些属性的问题”。Allbery 说他相信 tmpfs 支持所有三种时间戳。

有些人将信息存储在 /var/tmp 中以供长期运行的作业使用，因为他们希望在不进行备份的情况下保存这些信息，Barak A. Pearlmutter 说。Boccassi 驳斥这一点，他说，那些用户“假设他们真的存在”，可以根据自己的需要自定义系统默认值。

这些用户确实存在，Jonathan Dowland写道 ，“[我]一直是其中之一，我与许多人合作过，这是学术计算中非常普遍的模式”。对这些文件的处理方式进行更改，“应该是一个经过认真探索的决定”。他还要求提供支持更改的论据，并要求推迟更改以让讨论继续进行。

Hartman 希望 是不是能指定 /var/tmp 下的目录应该被完全删除或保留。Boccassi 说这是一个合理的增强请求，并且已经在上游提交给 systemd。

Allbery 最终承认惊讶于报告使用 /var/tmp “用于明显不是传统 UNIX 意义上的临时文件”的人数之多。他说，定期删除 /var/tmp 中的文件至少是 30 年来的常见 UNIX 实践：

无论我们对 /var/tmp 保留做什么，我都恳请人们停止将 /var/tmp 用于您保留超过几天并且不希望丢失的数据。这不是它的用途，您 总有一天 会在 某个地方 中招，因为即使在现有的 Debian 配置下，许多人也会运行 tmpreaper 或类似的程序。如果您正在运行一个产生您关心的数据的长期运行任务，请为此创建一个目录，无论是在您的主目录、 /opt 、 /srv 还是其他地方。

Hakan Bayındır 说 他没有使用 /var/tmp ，但其他人使用的应用程序会使用它。他引用了一个高性能的科学应用程序，该应用程序不受他或其他用户的控制。Allbery 认为这是一个“不好的设计决策”，但他承认如果用户或管理员无法控制应用程序的设计，这可能没有帮助。但是，他说，以这种方式使用 /var/tmp “是在玩火”，并且“最终会导致某些人的数据在某个时刻被删除，无论 Debian 做什么”。

Lewis 说他仍然不明白更改的理由。他问道：“也许除了‘其他发行版和上游已经这样做了’之外，还有更令人信服的理由吗？” Allbery 说，这听起来像是最初的理由，但他补充说，将 /tmp 移到 tmpfs 应该会使应用程序运行得更快，并且收获 /var/tmp 下的文件可以帮助避免填充分区。他指出，允许分区填满会导致邮件被拒收、服务不稳定以及其他问题。这可能对桌面系统来说不是问题，桌面系统往往有足够的磁盘空间不受影响，但对于将 /var/tmp 包含在小型根分区中的虚拟机来说，这仍然是一个问题。

推出更改

最终，所有维护 Debian 现状的论据都没有说服 Boccassi 改变主意。5 月 28 日，Boccassi 宣布了他所做的更改，并将其上传到不稳定版本。正如预期的那样， /tmp 默认情况下将成为一个 tmpfs，适用于 Debian 不稳定版本的新安装和现有安装。新安装将使用 systemd 的默认行为。他说， openssh 和 tmux 软件包已经修复，以提供例外情况以保留其临时文件。在 Debian 安装程序中添加了一个描述，通知用户 /tmp 默认情况下是一个 tmpfs，并且这些更改已在 NEWS 文件中记录。他还提议审查并合并对 Debian 安装程序的任何更改，以便用户在安装过程中自定义这些选项。想要将 /tmp 保留在磁盘上的用户可以使用 systemctl mask tmp.mount= 覆盖上游默认值。要停止对 /tmp 和 /var/tmp 的定期清理，用户可以运行 touch /etc/tmpfiles.d/tmp.conf 。

需要指出的是，所有这些更改都不会影响 Trixie 之前的 Debian 版本。Debian 稳定版和旧稳定版用户只有在升级时才会遇到这些更改。

如前所述，许多发行版已经在没有造成灾难的情况下进行了这些更改。Debian 及其用户应该能够适应新的默认值，或者在默认值不适合要运行的工作负载时覆盖它们。最糟糕的情况是，这只会带来暂时的不便。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～