Files In /tmp Disappear

[tony j. podrasky]

Hello Everyone;

O/S: Fedora 16

--

Something keeps deleting files in the /tmp directory.

I've deleted <tmpwatch> but it is still happening.

I've looked in /etc/tmpfiles.d and did a "grep * tmp" but there were no entries referencing the /tmp directory.

Question:

o Does anyone know what is doing this?

o If it is <systemd-tmpfiles>, what is the command sequence to turn it off?

regards,

tonyp

[Dennis Handly]

What's the permission on /tmp/?  Does it have the sticky bit set?

[tony j. podrasky]

Hello;

Yes, it does.

regards,

tonyp

[Matti_Kurkela]

Is there anything common with the files that keep disappearing? For example, are they created by a particular service/daemon, or a particular user?

Are you aware that Fedora 16 and newer can make /tmp private for services that have been configured to use that feature?

http://fedoraproject.org/wiki/Features/ServicesPrivateTmp

The infrastructure for that feature has been included in Fedora 16, and the applications were scheduled to start using it only at Fedora 17. But apparently some applications started to use it in the middle of the Fedora 16 cycle.

If that feature is in use, it might mean that when e.g. CUPS writes a file to /tmp, it is actually stored in some other directory, and that directory is presented to CUPS (and only to CUPS) as /tmp.

Also note that Fedora 18 apparently has a tmpfs-based (= RAM disk) /tmp, so everything stored in /tmp will always disappear when the system is halted. /tmp should never be used for long-term storage anyway.

[tony j. podrasky]

Hello Matti;

Thank you for your response.

I haven't tracked down when the deletes are happening.

It happens only to old files (likes ones from May or earlier). Doesn't matter who/what created them.

I've checked the logs and can't find any entry that would lead me to the culprit.

I've done a <locate tmp> and tracked down some systemd files in /lib/systemd/system that might be the cause.

I'm going to write a shell script to e-mail me the status of /tmp daily and watch when files disappear. Once I can nail down when it is happening, I can try disabling those files in systemd.

Oh - I use the /tmp directory to store all my edits with <vi> and other audit trails. Every month I back it up to my silo storage and then flush the /tmp directory.

regards,

tonyp

[Matti_Kurkela]

> It happens only to old files (likes ones from May or earlier). Doesn't matter who/what created them.

That definitely sounds like tmpwatch in action. I think the default tmpwatch setting for Fedora /tmp is about one month.

Earlier, you said:

> I've deleted <tmpwatch> but it is still happening.

Exactly what did you mean with this? Did you delete the cron job specification file, or the binary itself? Or did you remove the tmpwatch RPM?

Deleting the cron job specification or the tmpwatch binary may bite you if you have automatic updates enabled: if tmpwatch was updated after you deleted it, the RPM database would still show it as installed, and the updated RPM would bring back both the binary and the missing configuration file.

> Oh - I use the /tmp directory to store all my edits with <vi> and other audit trails. Every month I back it up to my silo storage and then flush the /tmp directory.

I'm sorry, but that is not exactly the expected use of the /tmp directory. (It's rather more like keeping important files stored in Recycle Bin when using a Windows or Mac system.)

In general, /tmp is for short-term temporary files only: those that should normally be kept only for some seconds, minutes or hours at most; usually not days. Basically, no longer than a single login session is expected to last. The contents of /tmp are usually also considered "fair game" for deletion at boot time, although not all Linux distributions will do that automatically.

See also what the Filesystem Hierarchy Standard has to say about /tmp:

http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES

For longer-term temporary files, there is /var/tmp. But for your purpose, neither is really the right place.

As you're a sysadmin, if you feel you need a place for vi editor backups and audit trails that is separate from your home directory,feel free to make one. For example, if you want a three-letter name for it, how about /bak?

You also might want to learn about revision control systems. For tracking changes in /etc, I would recommend etckeeper paired with a revision control system of your choice (git is recommended by etckeeper's author). It should be available in the standard package repository of Fedora, and at least on my Debian system, it needed only a few commands to set up:

$ less /usr/share/doc/etckeeper/README.gz
# vi /etc/etckeeper/etckeeper.conf  #Hmm, defaults are sensible - no changes.

then, according to the instructions in the README.gz file:

# etckeeper init
# cd /etc
# git status
# git commit -m "initial commit"
# git gc

 Then, after making any changes in /etc, I only need to run:

# cd /etc
# git commit -am "<description/purpose of change>"

 If I install or update any packages, the package manager will run it automatically for me.

If I forget, there's a cron job that will automatically commit any changes to revision control daily.

If I want to make a backup of my /etc for permanent storage elsewhere (including the full editing history of every configuration file!), I only need to run:

# mkdir /somewhere/etc_backup_directory
# chmod 700 /somewhere/etc_backup/directory
# cd /somewhere/etc_backup_directory 
# git clone /etc

 To update an already-existing backup to include the latest changes (faster than a full clone):

# cd /somewhere/etc_backup_directory
# git pull

 And what do you get with all of this?

Well... it's easiest to understand if you make a few commits, and then look for yourself, using gitk, the GUI tool for git:

# cd /etc
# gitk