LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Question about files in /tmp (http://www.linuxquestions.org/questions/slackware-14/question-about-files-in-tmp-4175502565/)

Phorize 04-22-2014 09:37 AM

Question about files in /tmp
 
I have just taken a look at my /tmp directory on a stock Slackware64 14.1 system with a few additions from slackbuilds. I have seen some new stuff in there and would appreciate opinions:

1) It looks like kget has been saving parts of downloaded files in /tmp (unless I have somehow copied a load of files into /tmp with realising (which is unlikely as I'm very cautious when logged in as root)-this seems very weird and quite concerning-has anyone else experienced this?

2) The following files are also present in /tmp:

Code:

libqemu-conf-10134-9211-28180.la
libqemu-conf-18352-10599-5372.la
libqemu-conf-32657-8845-16031.la                                                                                                                                                             
qemu-conf-10134-9211-28180.lo                                                                                                                                                               
qemu-conf-18352-10599-5372.lo                                                                                                                                                               
qemu-conf-32657-8845-16031.lo

I have qemu 2.0 installed using a slightly modified slackbuild (just the version number) from slackbuilds.org. I'm looking at the qemu documentation and can't see that there is any reason to use /tmp. Again, thoughts appreciated. I can't see that these would be left by the compile process.

All the best,

Kris

Didier Spaier 04-22-2014 10:12 AM

A lot of applications put temporary files in /tmp, as that's its purpose according to the filesystem hierarchy standard, that also recommends (but does not require) that files and directories in /tmp be deleted whenever the system is booted. I wouldn't worry about that, unless I have a reason to think that can compromise the system's security. I'd just check that these files do not occupy too much space. Some folks delete all files in /tmp once in a while, of when (re)booting or halting the system.

PS there have been similar (though maybe less specific) threads that you can find searching this forum for threads with "/tmp" in the title.

hpfeil 04-22-2014 10:13 AM

I have defined in .bash_profile: "export KDEHOME=$HOME/.kde4"
An old habit, I also have "export ME=`id -un`"
In $HOME/.kde4, I've created links to the kde tmp folders in /var/tmp.
If they don't already exist, mkdir -p
/var/tmp/kdecache-$ME
/var/tmp/ksocket-$ME
/var/tmp/kde-$ME

[I'm astonished at your patience if you've read this far!]

Go to `cd $KDEHOME` and create the following links:
ln -s /var/tmp/kdecache-$ME cache-$ME
ln -s /var/tmp/ksocket-$ME ksocket-$ME
ln -s /var/tmp/kde-$ME tmp-$ME

Then KDE4 will use those folders for it's temporary files and stay out of /tmp. You might have run a build script that places the results in /tmp for you to move elsewhere (/lib or /lib64) depending upon your architecture?
--
Obquote: "Need more input!" -Number Nine.

Mark Pettit 04-22-2014 10:20 AM

I was quite surprised to find that out-of-the-box, linux did NOT clean /tmp on boot. I came from a Unix SVR4 environment (AT&T Unix) and also Solaris and wiping it on boot was the norm. I think nowadays on Solaris, /tmp even resides in real memory (or swap), and is thus automatically destroyed on a reboot. You can safely delete anything in there at an early stage of your boot process. Preferably VERY early, as some processes start writing there and you'd not want to cause an issue. Also, never ever rely on data written to /tmp to be there afterwards - just as a matter of principle.

Didier Spaier 04-22-2014 10:44 AM

Quote:

Originally Posted by Mark Pettit (Post 5157094)
I was quite surprised to find that out-of-the-box, linux did NOT clean /tmp on boot.

I assume that distributions' maintainers consider that being the system administrator's job. So do I.

Bertman123 04-22-2014 10:45 AM

I use the attached link to clean the /tmp files when I shut down. I don't use my machine as a server so don't mind shutting down every night. Slack boots faster than XP did.

hpfeil 04-23-2014 11:46 AM

Slackbuilds creates /tmp/SBo with separate folders for extracted source files and build output. It then creates a package file from the build file. Temporary files like gpg's sockets, .ICE-linux, .X11-linux, gedit tmps, etc. are indeed deleted by the process that created them (two gpg processes ==> two gpg sockets). Surprise! The SBo intermediate build files, among others, are left in place for the sysadmin to clean out whenever the possibility exists that the files will be used again. SBo packages, for instance, might be collected for distribution or installation on other machines; if something goes horribly wrong it is quite convenient to have the build and config logs there.
If you really want to have a place to put stuff that is automagically deleted each power cycle, use /dev/shm (although the max that holds is half of physical ram). Some people even map $TMP to /dev/shm.

I don't know of a Slackware sysadmin who would use a script in /etc/rc.d to clear /tmp on shutdown. Bash has a convenient file named ".bash_logout" that if found in your $HOME folder, will run before deleting your login process. Something like `rm -rf /tmp && mkdir /tmp && chmod 1777 /tmp` if you use a convenient root console to jump into whenever you need to do rooty stuff.

catkin 04-23-2014 12:48 PM

Clearing /tmp on shutdown is probably OK but AFAIK clearing it on boot is always OK if it is cleared as soon as the file system containing /tmp is mounted with write access.

Having /tmp on the / file system, I have modified /etc/rc.d/rc.S to do so (change identified by #@ comment):
Code:

  # Remount the root filesystem in read-write mode
  echo "Remounting root device with read-write enabled."
  /sbin/mount -w -v -n -o remount /
  if [ $? -gt 0 ] ; then
    echo
    echo "Attempt to remount root device as read-write failed!  This is going to"
    echo "cause serious problems."
    echo
    echo "If you're using the UMSDOS filesystem, you **MUST** mount the root partition"
    echo "read-write!  You can make sure the root filesystem is getting mounted "
    echo "read-write with the 'rw' flag to Loadlin:"
    echo
    echo "loadlin vmlinuz root=/dev/hda1 rw  (replace /dev/hda1 with your root device)"
    echo
    echo "Normal bootdisks can be made to mount a system read-write with the rdev command:"
    echo
    echo "rdev -R /dev/fd0 0"
    echo
    echo "You can also get into your system by using a boot disk with a command like this"
    echo "on the LILO prompt line:  (change the root partition name as needed)"
    echo
    echo "LILO: mount root=/dev/hda1 rw"
    echo
    echo "Please press ENTER to continue, then reboot and use one of the above methods to"
    echo -n "get into your machine and start looking for the problem. "
    read junk;
  fi 
  #@ Empty /tmp on / file system now, as soon as possible after it is mounted rw
  ( cd /tmp && rm -rf -- * .* 2>/dev/null )


pan64 04-23-2014 01:28 PM

Actually my /tmp is in the ram therefore completely lost during reboot.
.la and .lo files were probably created during compilation (these are temp files not in use by the final executables).

ponce 04-23-2014 03:43 PM

Quote:

Originally Posted by Phorize (Post 5157066)
2) The following files are also present in /tmp:
Code:

libqemu-conf-10134-9211-28180.la
libqemu-conf-18352-10599-5372.la
libqemu-conf-32657-8845-16031.la
qemu-conf-10134-9211-28180.lo
qemu-conf-18352-10599-5372.lo
qemu-conf-32657-8845-16031.lo

I have qemu 2.0 installed using a slightly modified slackbuild (just the version number) from slackbuilds.org. I'm looking at the qemu documentation and can't see that there is any reason to use /tmp. Again, thoughts appreciated. I can't see that these would be left by the compile process.

I got those files too in /tmp on the machine where I built qemu-2.0.0 last week (I modified SBo's SlackBuild like you), so I suppose it's normal.

hpfeil 04-24-2014 11:22 AM

Quote:

I was quite surprised to find that out-of-the-box, linux did NOT clean /tmp on boot.
Actually, /tmp is indeed "cleaned up" in /etc/rc.d/rc.S early in the boot process.
=-=-=-snip-=-=-=-
# Clean up some temporary files:
rm -f /var/run/* /var/run/*/* /var/run/*/*/* /etc/nologin \
/etc/dhcpc/*.pid /etc/forcefsck /etc/fastboot \
/var/state/saslauthd/saslauthd.pid \
/tmp/.Xauth* 1> /dev/null 2> /dev/null
( cd /var/log/setup/tmp && rm -rf * )
( cd /tmp && rm -rf kde-[a-zA-Z]* ksocket-[a-zA-Z]* hsperfdata_[a-zA-Z]* plugtmp* )
=-=-=-snip=-=-=--

It also does the "chmod 1777 /tmp /var/tmp" which I incorrectly suggested had ought to be done in root's .bash_logout. /etc/rc.d/rc.M cleans out some more plerf from /tmp. The statement "out-of-the-box, linux did NOT clean /tmp" is false. I point that out only because search engines have a nasty habit of finding such false statements and presenting them as if they were true.
Disclaimer: This post is not an "ad hominem" argument.

BCarey 04-30-2014 09:59 AM

You can use RAM for /tmp, as alluded to above by pan64 by adding something like
Code:

tmpfs  /tmp        tmpfs  nodev,nosuid          0  0
to your /etc/fstab. Then you will always have a clean /tmp when you reboot.

It will expand as you use it by default up to half of your RAM. Otherwise you can use size=X in fstab to specify a maximum size.

Brian

jpollard 05-02-2014 05:54 AM

One problem on servers using tmpfs for /tmp is that you can deadlock the system by using shared memory (keys in /dev/shm) as each can use up half your memory. In addition, there are no quota controls to moderate /tmp use.

BCarey 05-02-2014 11:15 AM

You can set maximum sizes by adding, for example, size=1G as a mount option.

ruario 05-02-2014 01:53 PM

Perhaps there are better ways but this has workd for me thus far:

Code:

$ cat /etc/rc.d/rc.local_shutdown
/usr/bin/find /tmp -mindepth 1 -maxdepth 1 -exec /bin/rm -rf {} \;



All times are GMT -5. The time now is 12:36 PM.