Need an lternative for lsof command
 

Hi,

In my bash script I need to move files in a folder if it is not in use.

It worked fine sometimes but sometimes it just get stuck at lsof.
Is there any other way that I can use here to check if the $entry is using some other process?
Or am I using this wrong?

Appriciate your ideas :)

Not sure what you mean by 'it worked'. According to my logic, the variable '$ru' can only ever get the value 'COMMA'.

You don't need the initial 'ls' command:
If the filename in '$entry' contains whitespace, it will cause lsof to fail, so enclose the filespec in quotes:
Note also the use of the '$( .... )' notation which is preferred over `backticks`.

On any files/directories that I tried, lsof always reports with a heading line:
, so the result of the bash substring extraction is always 'COMMA'.

What is this intended to accomplish? It isn't obvious to me from the given context.
An alternative algorithm might be to parse the output of lsof (no args).

--- rod.

Hi,

I don't need the output of lsof, what I need to know is if the file $entry is using by another process.
If it is in use it lsof gives out something otherwise nothing. When I catch the output of lsof to $run & compare it to be empty in if statement it tells something string too long. That's the only purpose of $ru value.
If $entry not in use it should be moved to somewhere else.

Hope I explained clear now & you can help me..
Thanks!

So your problem is that sometime lsof won't return "at all"?
It just hangs, and your loop doesn't get executed?

Btw, you wouldn't really need to capture any output:


Cheers,
Tink

Exactly!
It just hungs there at lsof (doesn't print the 2ns $entry in code).

Do you know why it happens?
Any solutions for that?

I've seen lsof take its time, I never saw it fail ... on such an
occasion where it fails, can you check with strace what it's doing?

strace -vFf -o ~/lsof.out -p <lsof PID>


If you don't want to go down the route of finding out why lsof
is failing, you could use "fuser" instead.


Cheers,
Tink

So, why not just grep the output of lsof?
--- rod.

That's even worse :}

His problem is that sometimes lsof doesn't return. That will be
the same (or worse) if he gets ALL open files, and greps for the
entry. Plus it would increase the runtime if it runs to completion.


Cheers,
Tink

It seems probable to me that the argument being passed to lsof has something to do with why lsof is misbehaving. Running it without any argument gets around that. It could be run once only, the output saved to a file, and the file parsed iteratively for each of the files in the specified directory. It may require a bit more careful parsing that my simple example, but that is a minor change dictated by the purpose. I just don't buy that lsof is somehow broken. I'm not saying that using fuser isn't a reasonable approach to the problem; rather that the way in which lsof was used by the OP seems suboptimal.

--- rod.

If lsof doesn't return when invoked w/ a file/directory path as
an argument it's broken as far as I'm concerned. The only valid
reason for it to fail would be that a mountpoint/fs has become
unavailable, e.g., an NFS share went down, an HDD died. In these
cases an invocation w/o parameters would fail in the same way: it
just won't return.



Cheers,
Tink

Hey Tink you are great! the directory /root/shared_storage/ contains some directories mounted to NFS. And moving input directory to /root/ almost solved the problem. :)

Thanks a million to you all for making me like Linux!!