4

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.

Improve this question

3 Answers 3

Reset to default
8

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!

Improve this answer
1
  • Very interesting and useful answer. Those file are created from 7 to 8 am. So I'll try to monitor them on that time range and I'll let you know.
    – Matteo Alessani
    Jun 17, 2011 at 7:07
3

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).

Improve this answer
1

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.

Improve this answer
1
  • The owner is root. Maybe some cronjob. There is a long job starting at 4AM but it's already completed for that time.
    – Matteo Alessani
    Jun 17, 2011 at 7:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .