Since /tmp is writable for all the scripts you see most likely are just collateral, not the actual compromise. And while dropping for instance a Perl backdoor script in /tmp the "noexec" mount flag would prohibit one from executing the script directly, calling it from the web application or prefixing the interpreter in the CLI one could still run it. Also please be mindful taxonomy-wise calling something a root compromise or a machine as "rootkitted". I mean a LAMP stack compromise may result in a root compromise but it does not have to. Probbly superfluous to say but more than half of securing /tmp means preventing events from taking place by not disabling SELinux or GRSecurity, by properly hardening the machine, regularly auditing it, actually reading reports and adjusting the configuration.

* OTOH if you have access to or reports of rootkitted machines then I'm always interested in hearing about those in the Linux Security forum.

Whatever gave you the impression it would be "better" in any way?
Tmpwatch has checks built in to avoid race conditions and stuff.
This kludge has not.
YMMV(VM).

Hi UnSpawn. What makes you call it a kludge?

As in "does it's job without giving thought to other aspects"? Also see: a hack, a workaround, cobbling up something.

Thanks That's a good explanation of what "kludge" means but which "other aspects" do you have in mind? The technique is used immediately after /tmp has been mounted (or immediately after it has be re-mounted rw) so nothing new has been written to /tmp. The only files-and-directories under /tmp are ones from before shutdown ...

I'll mention configurability and security but since I mentioned 'tmpwatch' maybe you could spare 1 minute and look at its features?


I wonder if that is an assumption or an observation? If it is an observation does it apply to only that specific machine or to a range of machines possibly with different purposes and reboot schemes? And how would this behave if there are files that should not be removed on reboot? Say collateral from a breach of security? And to a (way) lesser extent, how about the time it requires to recreate default files and directories created at boot for use by subsystems?

Thanks, I'd already done that; it looks useful and thorough but I still prefer a "good enough" solution that does not require an extra package -- as long as it is "good enough", which concern is my reason for asking these questions.

It's an assumption but seems like a reasonable assumption -- unless there are any processes already running, waiting for /tmp to become writeable when they will write to it.

Good point regards observation; I've added a line in rc.S to show what is there but, as you point out, this can only ever yield system-specific data from which it is impossible to generalise with certainty.

Regards "files that should not be removed on reboot" I am in the happy position of having a system on which it is OK for things to break if such files are removed, on which it is OK to experiment.

I do not know enough about files "collateral from a breach of security" except to think out loud that rebooting a possibly-compromised system could destroy a lot of evidence besides files-and-directories in /tmp; if it has to be shut down (as opposed to disconnected from the network) then wouldn't a serious investigation require disk imaging before any reboot?

No, I don't have such a file. Is that a file the system makes, or can I just add it myself? I do have an /etc/init.d/halt.

BTW: I noticed a number of other contributors to the thread mentioned deleting at different runlevels. Was it via such a file that they did this?

Ahem! I never said that it would be better. The way I phrased the question does not imply which I believe: that it is better or not. The way I phrased it actually suggests the opposite of what you assumed, the double question mark suggests that I thought it was not better.

Now that you have spoken out about the superiority of tmpwatch, I will use that instead of the 'kludge'. You have explained that it has necessary checks built in, an important fact that could take a long time to figure out from the man pages.

Thank you.

That's all very nice, but don't forget: the people who are reading your posts do not all make this assumption about their systems. You should not give advice that will break others's systems just because YOU are in a "happy position".

Tmpwatch may have a dizzying array of options, but at least it will not break anything.

The answer does not still seem simple after looking at the man page for tmpwatch

For that matter, now that I have looked into it, I see that my Fedora11 system already has, by default, a crontab entry to call tmpwatch, yet the files are still slowly accumulating.

The call (in cron.daily) is:

/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 10d /tmp

Now as I read this, this is a command to delete everything aged over 10 days in /tmp EXCEPT the explicitly named directories (well, I admit, I don't know what $flags is set to at the time).

But I see stuff that is obviously not in any of the above directories persisting in /tmp, such as virtual-mejohnsn.VRsASs, which is dated 2009-10-11, so it should have been deleted (over 10d ago).

So how do I go about figuring out why tmpwatch isn't deleting such files?

The phrase you used, "does it's job without giving thought to other aspects", sets off a warning bell in any experienced programmer's head. That warning bell is the alarm bell warning of a kludge.

Besides that, he gave a better reason: that tmpwatch is designed to take into account ALL the necessary safeguards, the very safeguards people are usually ignoring when they say, "does it's job without giving thought to other aspects".

There is a world of a difference between ignoring side-effects and designing loosely-coupled code to avoid the need to consider side-effects.

Thank you for your concern.

Deleting temporary files is always uncertain unless you have a thorough knowledge of everything that creates them -- and this is not practically acheivable.

Just because a file was created, modified or accessed more than <whatever> time ago does not mean that a badly written application will not break if the file is deleted. PID and lock files are good examples.

The end result is that deleting temporary files is always a gamble. Some sysadmins solve the problem by never deleting them. Others use the likes of tmpwatch or find to delete files according to age criteria -- with or without "delete all at boot".

In none of these scenarios (except never deleting) is the sysadmin 100% confident that nothing will ever break. Like scientific hypotheses -- that can never be proven correct but only falsified -- we can only become more confident as time and usage does not reveal any problems.

In this situation, with a newly installed system, it is a reasonable strategy to delete all temporary files at boot. I have done so without problem on every *n*x system I have been responsible for without ever having a problem. This principally on development server farms but including several production servers.

The only time I had a problem was when some developers had got into the habit of using /tmp as their personal dumping ground; that was solved by backing up before deletion and restoring to their home directories when they wanted their files back.

@mejohnsn You wrote "You should not give advice that will break others's systems". Quite right! And I don't think that I did although, of course, pretty much anything can cause breakage in unforeseen circumstances. Let's look at my post.

I asked LQ if there were any reasons for not doing what I have implemented (without problem on multi-user servers around the globe including mission-critical servers), I showed how I had done it and reported "no breakage so far". That does not advise anyone to do it. It is not something that "will break others' systems" (although it may, of course, cause some breakage on some systems -- as may tmpwatch).

Your post is incomplete: if unsure best post complete, unedited cronjobs. The "$flags" variable is set at the top of the cronjob and holds the switches 'tmpwatch' uses to determine what checks to perform and what attributes to look at. This could for example be flags="-umc" to only look at (file) access, modification and change time or flags="-mMds" to perform a 'fuser' check on files (file in use or not), check file and directory modification time, and not remove directories.


First thing to check is what kind of file "/tmp/virtual-mejohnsn.VRsASs" is (run 'file' on it). To test removal for this purpose add the "-t" flag. This will make 'tmpwatch' go through the motions but without actually deleting things. If the file is not a regular file add "-a". Now to test things run:
Tell us if the file does not show up.

Sure. Entirely your choice.


Yes but that's not my point. It's about what tasks one may expect a system to perform on bootup. Yours wipes everything, without regard for anything and without a user being able to stop it.


I really would like to go into what you wrote later on, particularly the part, but I think I've given you enough food for thought (which you're obviously free to ignore).