I am mystified by the files accumulating in /tmp. I have been running Fedora11 for just a few weeks, but I already have 2832K of files in there.

I thought the programs that created files in /tmp were responsible for deleting them when done. But clearly, that is not happening, at least not always.

So the question is: when is it safe for me to delete them? Or is there some reason these programs are failing to delete them themselves, and some way for me to fix that?

2823K? who cares about 2.3 megabytes of temp files?

/tmp is generally a tmpfs filesystem, which is an in-memory filesystem which will not persist a reboot. Files won't necessarily clear themselves up, but there's very seldom anything interesting in there, just lock files and such, unless you use it for other files, which you're perfectly entitled to.

I would advise against apatch to security around /tmp. While normal files are ignorable, /tmp itself is the target of things like rootkits... I am in the opinion that /tmp should always be a seperate partition with noexec, nosuid and nodev options active, even on desktops. I have seen a number of rootkitted machines with scripts in /tmp....

Speaking for myself, I have deleted files in the /tmp directory many times with no problems at all. 2mb might not seem like much these days but I still remember running with a 120mb hard drive some years back and I got in the habit of cleaning stuff up all the time and I still do. It makes me feel better.

That's nice, but what has "a patcfh to security" got to do with the questions?

Generally? Well, now that you mention it, I see the Install CD that made the decision to mount /tmp as /dev/shm, which sounds like "shared memory". Yet it is most certainly persisting past reboots.

As for what is in there, I am seeing PDF files I chose to view instead of download in Firefox -- and lost of files like "virtual-mejohnsn.Sj4G9C".

I can't specifically speak for a Fedora system, but on my Slack system, if I want to clear out /tmp I switch to init 1 before a reboot, delete everything in there, and reboot.

Much of the stuff in there will come back over time, depending on system usage; as mentioned, there are lock files and odds and ends and stuff that get created on a regular basis, but aren't necessarily deleted by whatever creates them with any regularity.

For the record, my /tmp persists over reboots too.

Sasha

If it's in /tmp and you reboot you shouldn't expect it to be there. So you can delete the contents early in the boot process or late in the shutdown process.

SUSE distros have a setting CLEAR_TMP_DIRS_AT_BOOTUP in /etc/sysconfig/cron that you can set to "yes" and that will delete any files in /tmp that don't belong to root whenever you reboot. Does Fedora have something equivalent to that? A quick Google didn't bring up anything.

Have you got a file /etc/init.d/halt.local ? If so you should put something like 'cd /tmp && rm -rf *' in there.

Slackpackages I make are all placed in /tmp prior to installing them; if you want to reinstall one of those without recompiling it you might want to save those elsewhere prior to wiping /tmp

Simple question, simple answer, see: tmpwatch.

For a system that is booted regularly are there and reasons for not deleting everything in /tmp as soon as it is mounted? I've modified /etc/rc.d/rc.S (this on Slackware 13.0) changing this original linetoNo breakage so far. On long uptime systems I used to remove anything more than 7 days old from a daily cron job. Half-expected some breakage but never had any.

Well good spelling would help, it doesn't directly relate the question, I was pointing out that a statement of 'it's /tmp it doesn't matter' is extremely bad behaviour considering how exploitable /tmp can be.

But why is this procedure better than using 'tmpwatch' in a cron job??

I agree that that is an important point. So despite your (ahem!) complaint about the typo, I clicked on the blue thumb.

It's not better, just an alternative (and I like solutions that don't require installing another package).