/tmp 目录：0 个文件但显示已满？

Question

与另一篇文章相关，由于另一张海报，我终于能够删除 /tmp 中的文件。

但是，最终系统管理员不得不恢复几天前的快照才能备份 mysql 服务。

我推断 mysql 服务器没有运行，但事实并非如此。一个错误是它无法写入 tmp 目录以创建 mysqld.sock/.pid 文件，因此它们不存在。

因此，服务器重新启动/重新启动并最终从以前的快照中恢复，因此现在一切正常，但该快照来自几天前，因此告诉-告诉标志在此输出中：

drwxrwxrwt  2 root  root  34471936 Oct  8 20:47 tmp

那个大数字仍然以某种方式被“记住”，我试图找出写入该文件夹的内容？在 Drupal 中，预览文件的路径设置为该目录，但我只是进行了一系列测试（该站点没有登录帐户/仅用于数据）下载、预览等，并且 /tmp 文件夹中的文件号从未更改，那又怎样正在写入该文件夹？

这是一个网络服务器，除非出现问题，否则不会关闭/重新启动。即便如此，/tmp 目录在重新启动时也不会被清空。此外，在 rsC 文件中，TMPTIME=0仍为默认值。

因此，我不确定在3441936实际目录为空时还可以在哪里查看或如何调查保持该大小的原因？或者，如何搜索正在使用该目录的进程。

这仅适用于 Drupal 安装。Ubuntu 12.

Answer 1

尝试这个。

$ sudo lsof | egrep '^COMMAND|deleted'

我在系统上看到的示例输出...

COMMAND     PID        USER   FD      TYPE             DEVICE   SIZE/OFF       NODE NAME
mysqld     2842      mysql    5u      REG                9,1        4633    6209543 /tmp/ibLRNV1i (deleted)
mysqld     2842      mysql    6u      REG                9,1         424    6209545 /tmp/ibnnYl1y (deleted)
mysqld     2842      mysql    7u      REG                9,1           0    6209546 /tmp/ib5ViM0O (deleted)
mysqld     2842      mysql    8u      REG                9,1           0    6209547 /tmp/ibh9U55F (deleted)
mysqld     2842      mysql   13u      REG                9,1           0    6209548 /tmp/ibRzqtwm (deleted)
mysqld     2842      mysql  319u      REG                9,1    25894907    6209553 /tmp/MLFxqPDX (deleted)
mysqld     2842      mysql  350u      REG                9,1   267677827    6209550 /tmp/MLFBkHbP (deleted)

许多 *nix 文件系统的一个共同特征是，没有什么可以阻止进程继续读取/写入已删除的文件，也没有什么可以阻止删除进程仍然打开的文件。

某些程序确保临时文件不会残留的一种方法（也可能作为一种安全措施，尽管我不确定这有多“安全”）是打开它们，然后立即“取消链接”（删除）它们。如果进程意外终止，则会释放磁盘空间。MySQL 这样做：

MySQL 安排在 mysqld 终止时删除临时文件。在支持它的平台（如 Unix）上，这是通过在打开文件后取消链接来完成的。这样做的缺点是名称不会出现在目录列表中，并且您看不到填充临时文件目录所在文件系统的大临时文件。（在这种情况下， lsof +L1 可能有助于识别与 mysqld 关联的大文件。）

^{— http://dev.mysql.com/doc/refman/5.6/en/temporary-files.html}

要点：当一个仍然打开的文件被删除时，磁盘上的空间实际上并没有被释放，直到最后一个持有文件句柄的进程关闭它。在文件关闭之前，除了杀死进程之外，没有人（包括 root）可以释放该空间。相反，杀死（或优雅地停止，如果可能的话）进程应该总是释放空间。

所以我建议你看看你的系统在打开和删除文件方面可能有什么，这可能会给你一些事情要做。

就我的系统而言，MySQL 确实打开了许多临时文件，其中一些相当大。

如果您想查看这些文件的内部情况，这很容易完成，尽管您能够识别的内容的性质差异很大。以 PID 和 FD 下的数字为例，PID 2842 FD 350：

$ sudo strings /proc/2842/fd/350 | less

如果 MySQL 确实删除了打开的临时文件，停止并重新启动 MySQL 将释放该空间，然后您需要调查可能是什么原因使这些文件保持打开状态，这些文件停留的时间过长，以及是否有生成过大的查询临时表并耗尽您的 /tmp 空间。如果您的 /tmp 目录是它自己的分区/文件系统，那么df -h它将为您提供有关可用空间和已用空间的更好答案。您可能不需要过多担心目录条目本身的实际大小。

当然，它可能不是 MySQL。:)