有时候，在我的Linux Debian服务器上，我发现了一大堆超过30MB的sorting*文件（sort0ylf0b，sort8KXDHC，sortCoMKVq）。 谁在/ var / tmp中创build这些文件？
我尝试谷歌，但没有。
有任何想法吗？ 谢谢。
我不确定是什么原因造成的。 如果文件仍然处于打开状态，您可以使用'lsof'（代表“打开文件列表”）工具查看打开了哪些进程：
lsof /var/tmp/sort* 如果这些文件中的任何一个当前处于打开状态，您将看到一些类似于此的输出（除了我在/ tmp / *上运行了lsof之外）：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME xmms2d 28523 jonhall 3u unix 0xffff880025052100 0t0 2272384 /tmp/xmms-ipc-jonhall xmms2d 28523 jonhall 11u unix 0xffff880194d7de00 0t0 2272401 /tmp/xmms-ipc-jonhall
您真正关心的输出中唯一的信息就是PID。 尝试这个：
ps 28523 # Replace the number with the PID from your own output, obviously
你应该看到罪魁祸首：
PID TTY STAT TIME COMMAND 28523 ? SLl 11:30 /usr/bin/xmms2d --status-fd=4
在我的情况下，xmms2d是什么文件打开。
这一切都取决于lsof给你一些有用的输出，但。 如果没有，请尝试多次运行相同的lsof命令。 如果这些临时文件的大小是30MB，那么需要一点时间（也许是几秒钟）来写这些文件，所以如果你能够“在行为中捕获它”，lsof应该告诉你你需要知道什么。 当然，这一切都取决于这些文件的写入频率。
祝你好运！
这些文件很可能是由于定期运行updatedb （用于locate命令）而创build的。 我在cygwin中发现了同样的问题，其中/var/tmp超过了5年前的几个旧文件。 （在我的系统中， updatedb是一个调用mktemp的脚本，它使用$TMPDIR当前设置的任何内容; updatedb将其设置为/var/tmp ）
/var/tmp目录传统上不会在重新启动时被删除，而/tmp将是; 同样， /var/tmp通常是一个由磁盘支持的较大的分区，而/tmp可能只是内存（导致updatedb失败或使用空间不足（内存））。这些假设可能不适用于您的系统; 在“修复” updatedb的情况下，您可以（取决于平台）更新/etc/updatedb.conf来写入/tmp而不是/var/tmp 。 （或者运行定期清理旧/var/tmp/sort*文件的cron作业。）
作为参考，看看这个debian的bug （closures为“不是一个错误”，因为它是一个configuration更改）。
谁是这些文件的所有者？ 有时候可以给你一个提示。
一般来说，如果sort必须通过大量文件进行梳理，则会生成这些文件。 它在sorting某些海量数据时使用这些文件作为临时文件。