strange fuser output

[Michael Murphy_2]

Hello - I am working on a cleanup script for /tmp and was going to remove all files a certain age - as an added check I thougth I would run fuser on the file to verify that it was not in use. I tried testing this by vi'ing a file and running fuser against it - it does not report a process id. Any clues why? Is there another way to do what I am trying to do? THanks...

[Steven E. Protter]

Shalom,

Most of the rest of the systems administration world is okay with nailing files of a certain age on /tmp

This check sounds like a nice idea, but the fuser output seems to need a sysadmins eyeballs for interpretation.

You test should work. When you vi a file there is definitely a file handle on it and fuser should show it.

Perhaps your system is short on resources, and that causes the delay.

Overall I think trying to user fuser is overengineering. Can you post some sample code?

SEP

[Jeff Schussele]

Hi Michael,

I assume you're running a find command to locate these files & then piping to fuser.
Try the other direction, i.e. use a simple l command to find all files there. Then,using lsof instead of fuser, find all files *actually* open in that filesystem/dir & rm the ones that aren't.
You'd have to build a file or array of all files there (open or unopen) but it's much likelier that they will be "unopened" when the fuser hits. There's no way to guarantee that open files will still be open when the fuser executes.
Other option is to test for open *immediately* before fuser & a conditional that if the file is not open anymore, move on & don't exit. The nfile table is *very* dynamic & can't be "trusted" for more than a few milliseconds.

Rgds,
Jeff

[A. Clay Stephenson]

Neither fuser nor lsof would likely detect that the file was open because it is in fact open only briefly by vi -- for reading or writing. Vi reads the entire contents of the file into memory and then closes the file. When vi write's the file back out, it opens the file, dumps its internal image to disk, and again closes the file.

Now, whack your script writers and developers with a baseball bat on account of ain't nobody but the OS supposed to be writing in /tmp; other temporary/scratch files should be written in /var/tmp unless overidden by the TMPDIR environment variable.

[Rory R Hammond]

I disagree slightly with Clay. vi makes a copy of the file, and put the copy in /var/tmp (at least on my systems). You can easily test this by looking in /var/tmp

I have used a program for many years that examines (st_ctime). If a file has not changed for 12 hours the file gets deleted.

Depending on the system and applications, I have to exclude a few files. I also have to be careful with some directories like lost+found.

Rory