How to identify any processes running on a huge directory structure?

[Steve Post]

I have a big directory structure with lots of junk in it. I want to make sure it is not being used before I delete it. Is there a utility, or should I run fuser FILENAME, 259,432,343 times?

[Torsten.]

IMHO the tool lsof is better than fuser here.


But it is still hard to decide.
What if the files are not currently open, but an application will need it later?


Whatever you will do, backup the files before delete them.

[James R. Ferguson]

Hi Steve:

You don't say, but if the directory is mounted, you won't be able to unmount it until there are no open files and/or no one is 'cd'ed into it.

Regards!

...JRF...

[Steve Post]

"IMHO the tool lsof is better than fuser here." I don't want to lsof 259,432,343 times either.

The directory I am talking about is not a filesystem. It is a sub,sub,sub-directory of a filesystem. It is an old copy of perl.

Maybe I could do this in reverse? Is there a command that identifies files in use given a list of processes? I know that I have a small set of apache test websites that might be using this subdirectory. I'd rather run a command 30 times instead of, well, a LOT of times.

On a side note, the idea of shutting down the computer will make sure the files are not in use. WELL....That is until I bring it up again, then some unknown application would go nuts trying to use files I trashed. THAT's no good.

[Matti_Kurkela]

In Unix, there is almost always more than one way to do things. Here are a few that came to my mind for a case like this:

- A single "fuser -c " will list you all processes running on the filesystem. That is likely to be much less than 259 432 343 processes. Then "lsof -p " can be used to tell what each process is accessing, unless you happen to know it by some other way (e.g. by recognizing the process and knowing what it *does* use). If that is still too long a list, then pipe it to "grep sub-sub-sub-directory" to see at once whether it uses your directory structure or not.

- lsof +D can do the job at once, although the man page warns it might be slow and take quite a bit of memory to run. If it outputs anything at all, you'll know something is using one of the files within the directory structure.

- If you choose to use fuser, you probably will need to run fuser a considerably smaller number of times if you put multiple filenames on each line. And you certainly don't have to type any of those lines yourself. Instead, you should type something like:

find -exec fuser \+

...and let the machine do what it can do best.

MK

[Steve Post]

It looks like I need to get tutorials on lssf.

...and need to give Torsten a few more points.

[Steven Schweda]

> On a side note, the idea of shutting down
> the computer will make sure the files are
> not in use. WELL....That is until I bring
> it up again, then some unknown application
> would go nuts trying to use files I
> trashed. THAT's no good.

Why "trash" the files? Why not simply rename
the top-level directory (before the
shut-down), and then wait for complaints
after you bring it back up? If you get none
(within some interval deemed to be
"adequate"), _then_ you can delete ("trash")
the directory tree. If you get some, then
simply rename it back to what it was.

"Seemples".

[Steve Post]

The idea of moving stuff and waiting on complaints is drastically dependent on what the complaints will be, and from who they are coming from. I have to be responsible. That might mean that I cannot allow a situation that causes complaints.

Ah. But you know that.

[Torsten.]

I see a lot of problems here, but not really a simple solution ... :-(


Assuming the directory is deep under let's say /opt, everything related to the mountpoint is difficult (unmount, actions related to the mounted lvol, etc ...).

However, if you say it could be related to apache, what will likely happen?

The files are sitting around doing nothing (not opened).

If a user opens a link to a script, the script will be executed, the files opened and closed again.


In such case looking for open files will not give you the results you want to have.


IMHO there are 2 possible solutions:

- don't touch anything
- trial and error


Maybe 1) is the better solution ...


;-)

[Jose Mosquera]

Hi,

Audit your mount point several times by several days to observe the behavior inside. Uses your desired tool (lsof or fuser) to do this. :)

Still, if you doubt to delete something, move it to a recycling point.

Rgds.