Housekeeping /tmp

B

balanga

I've just been checking through my /tmpdirectory and see over 50 files called tpl-*dating from 14th May.

Can I safely delete these files?

Are there any guides on how to do any housekeeping on /tmp
 
You could add the following to rc.conf(5) to have /tmp emptied on startup:
Code: 
clear_tmp_enable="YES"
I would wager that the files you see can safely be deleted but you can check whether they are currently in use using fstat(1): fstat /tmp/tpl-*

If you're worried they might not be in use now but are needed by an application then try moving them somewhere else, use your machine for a while and see whether any of your applications complain. If so, move the files back, if not then delete them for good.
 
wblock@ said:
Use tmpfs(5). Not only is it faster and more efficient than a drive-based directory, it self-clears when the machine is reset or powered off.
Click to expand...
So what is the caveat? Why is the driver not compiled into the generic kernel if it is so good? It must be a very good reason :)
 
Oko said:
So what is the caveat? Why is driver not compiled into the generic kernel if it is so good? It must be a very good reason :)
Click to expand...
There is no need to compile a custom KERNEL.

Code: 
/dev/gpt/system on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
tmpfs on /tmp (tmpfs, local)
 
Oko said:
So what is the caveat? Why is the driver not compiled into the generic kernel if it is so good? It must be a very good reason :)
Click to expand...
Like many things, it's just not enabled by default. I've had it enabled since version 7 point something, quite some time before it stopped being considered an experimental feature (that was back in 9.1R). And I've never had any trouble with it since.
 
Stop the stupidity please. The tmpfs(5) kernel module is autoloaded if needed when you mount a tmpfs filesystem:

Code: 
freebsd ~ % kldstat
Id Refs Address            Size     Name
 1    7 0xffffffff80200000 1fa7c38  kernel
 2    1 0xffffffff82211000 2acd5    vboxguest.ko
 3    1 0xffffffff8223c000 665d     nullfs.ko
 4    1 0xffffffff82243000 587b     fdescfs.ko
freebsd ~ % sudo mount -t tmpfs tmpfs /mnt
freebsd ~ % kldstat
Id Refs Address            Size     Name
 1    9 0xffffffff80200000 1fa7c38  kernel
 2    1 0xffffffff82211000 2acd5    vboxguest.ko
 3    1 0xffffffff8223c000 665d     nullfs.ko
 4    1 0xffffffff82243000 587b     fdescfs.ko
 5    1 0xffffffff82249000 adec     tmpfs.ko
freebsd ~ % mount
/dev/gpt/fb10root on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/gpt/fb10data on /data (ufs, local, soft-updates)
tmpfs on /mnt (tmpfs, local)
freebsd ~ %

This autoloading of filesystem modules has been in FreeBSD very long time, at least as long I've been a user.
 
  • Thanks
Reactions: Oko
tingo said:
And some of us store persistent data in /tmp and don't want it to clear out when the machine is rebooted. :)
Click to expand...
Use /var/tmp/ for that. See hier(7).

Code: 
     /tmp/      temporary files that are not guaranteed to persist across sys-
                tem reboots
Code: 
     /var/      multi-purpose log, temporary, transient, and spool files
{...}
                tmp/       temporary files that are kept between system
                           reboots
 
tingo said:
And some of us store persistent data in /tmp and don't want it to clear out when the machine is rebooted. :)
Click to expand...
I used to do that, too, but it's easy to lose things. It's like storing important documents in a trash can: sure, it works, but it only has to go wrong once...
 
tingo said:
And some of us store persistent data in /tmp and don't want it to clear out when the machine is rebooted. :)
Click to expand...
This is very wrong practice. /tmp is for temporary files only, mainly from applications. If your /tmp gets full then you will run into trouble.
 
You must log in or register to reply here.
Back
Top