Sometimes on my Linux Debian server I found a bunch of sort* files (sort0ylf0b, sort8KXDHC, sortCoMKVq) of more than 30MB each. Who create those files in /var/tmp?
I try to google but nothing.
Any ideas? Thanks.
Sometimes on my Linux Debian server I found a bunch of sort* files (sort0ylf0b, sort8KXDHC, sortCoMKVq) of more than 30MB each. Who create those files in /var/tmp?
I try to google but nothing.
Any ideas? Thanks.
I'm not sure what would cause that. If the files are still open, you can see what process has them open by using the 'lsof' (which stands for "list open files") utility:
lsof /var/tmp/sort*
If any of those files are currently open, you'll see some output that looks something like this (except that I ran lsof on /tmp/*):
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
The only piece of information you really care about in the output is the PID. Try this:
ps 28523 # Replace the number with the PID from your own output, obviously
And you should see the culprit:
PID TTY STAT TIME COMMAND
28523 ? SLl 11:30 /usr/bin/xmms2d --status-fd=4
In my case, xmms2d is what has the files open.
This all depends on lsof giving you some useful output, though. If it doesn't, try running the same lsof command several times. If these temp files are 30mb in size, it will take a little bit of time (perhaps a couple seconds?) to write them, so if you can "catch it in the act", lsof should tell you what you need to know. Of course, this all depends on how frequently these files are being written as well.
Good luck!
These files were likely created due to a periodic run of updatedb (for the locate command). I actually discovered the same issue in cygwin, where /var/tmp was over 5GB of old files dating back several years ago. (in my system, updatedb is a script that calls mktemp which uses whatever $TMPDIR is currently set to; updatedb sets this to /var/tmp)
The /var/tmp dir traditionally isn't deleted upon reboot, while /tmp would be; likewise, /var/tmp is usually a larger partition backed by disk, whereas /tmp might just be memory (causing updatedb to fail or run out of space (memory) if it were used.) These assumptions may not hold true for your system; in the case of "fixing" updatedb, you may be able (depending on the platform) update /etc/updatedb.conf to write to /tmp instead of /var/tmp. (Or run a cron job that periodically cleans old /var/tmp/sort* files.)
For reference, see this debian bug (closed as "not a bug", since it's a configuration change).
Who is the owner of those files? Sometimes that can give you a hint.
In general those files are generated if sort has to comb through a massive file. It uses those files as temporary files during sorting some massive data.