Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have certain files in a /tmp subdirectory that a script I wrote uses for scratch. The opens and closes these file perfectly fine for a few hours. Then, out of nowhere, the files are no longer found.

I looked in /var/log/messages and do not see anything that raises any flags around the time that the files disappeared.

Does anyone have any clue as to how I could troubleshoot this?

And yes, I know /tmp isn't the ideal location for files I care about but I still would like to know what causes this behavior.

share|improve this question

5 Answers 5

up vote 4 down vote accepted

Stock F14 only deletes /tmp files once a day and only if they are more than 10days old via /etc/cron.daily/tmpwatch.

You could use the auditing subsystem. Suppose the files are in the dir /tmp/help. In /etc/audit/audit.rules add

-a exit,always -F path=/tmp/help

Then restart auditd with /etc/rc.d/init.d/auditd restart. Here is what is logged in /var/log/audit/audit.log when I execute rm /tmp/help/heregoes:

type=SYSCALL msg=audit(1299113860.183:47): arch=c000003e syscall=263 success=yes exit=0 a0=ffffffffffffff9c a1=133a0c0 a2=0 a3=1 items=2 ppid=21286 pid=21328 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts361 ses=1 comm="rm" exe="/bin/rm" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1299113860.183:47):  cwd="/root"
type=PATH msg=audit(1299113860.183:47): item=0 name="/tmp/help/" inode=398818 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
type=PATH msg=audit(1299113860.183:47): item=1 name="/tmp/help/heregoes" inode=398819 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0

The first (rather long) line shows the executable, pid, and ppid, which may help.

share|improve this answer
    
Note that in empwatch "ten days old" is based on the atime (file access time) by default, but recent (last 3 years) versions of Fedora have a tmpwatch script configured to consider all of atime, mtime, or ctime. If you have your filesystem mounted as noatime, or are putting your files into /tmp with some method (like extracting from an archive) which sets old times, that might explain their "early" disappearance. –  mattdm Mar 3 '11 at 3:32

/tmp is used for temporary file storage. Usually it is cleared on boot and/or when it is full and/or on time bases.

I don't know how is it on fedora, but some other unix systems use /etc/init.d/bootclean.sh or cronjobs. `

share|improve this answer

Is there a problem if there is more than 1 instance of your script running at the same time?

If there is, try using $$ (which translates to the PID of the process running the script) in the filename. Something like

some_command > /tmp/output.$$

should do the trick.

share|improve this answer

Try installing inotify-tools and then using inotifywait you should be able to see exactly when the file is touched. Using a combination of inotifywait and lsof you should be able to see what process is touching /tmp/

SSH relies upon files in /tmp/ that exist for longer than hours, are other processes being affected by this problem as well?

share|improve this answer

Depending on your distribution the tmp files are possibly being wiped because they have been untouched for an amount of time.

Look for a cronjob named "tmpwatch", probably in /etc/cron.daily

It should definitely be more than "a few hours", the default is between 30 and 60 days.

share|improve this answer
    
Another common one is tmpreaper –  DerfK Mar 3 '11 at 0:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.