Greetings,
I need help understanding why FUSER will not bring back PSID's on mounted filesystems. Is this a common error?
Thanks in advance for your feedback.
Fuser works with files, not filesystems. What are PSID's ?
Can you give an example about what you think is an error ?
Hello,
Sorry for the delay. I work in the evenings. We have an FTP process that writes to an NFS filesystem. We have a daemon process that wakes up every now and then and issues an FUSER on the filesystem where the file is being FTP'd. When the daemon and the FTP happen on the same box, it returns the process-id's and user-ids of who has the filesystem open. However, when the FTP happens on a different machine(but the same NFS) the daemon / FUSER does not return the information, even though the FTP is writing to the filesystem. Any ideas? thanks so much for your help.
As I already commented, fuser works with files (including directories and devices) but not on file systems. Please explain better what your daemon is actually doing.
And how would an fuser process on one server be aware of a process on another server? It can't be.
Out of curiosity, how do you handle an FTP that fails in the middle of a transfer?
Greetings,
Thanks again for the support. The daemon issues an fuser on a file that is NFS mounted. So, (In theory) if a process has the file opened, the fuser would bring back the process id's and user-ids that have the file opened. It's a daemon process that was written before my time, and it has fallen on my lap to support. Currently, the daemon is moving grabbing files that are still being created by the FTP. Also, any ideas on how to identify if the FTP has not sent the complete file?
Here, fuser is properly detecting processes having a file open that is physically located on a remote server and accessed via NFS. On the NFS server side, no usage is detected as I was expected.
Uhhm. Let me try and understand your findings. So, if i have a file that lives on machine A and is mounted. I have a process running on machine A that has the file opened. I issue an fuser from machine B, will I or will I not be able to get the process id and user id?
Thanks.....
mounted ? I guess you mean that file is shared.
Is machine A the NFS server ? That process is accessing a file located on a local file system, correct ?
What is machine B ? You do not define its role here.
Yes, machine A is the actual location of the file that is NFS mounted. FTP process runs on machine A, creating a file in ~/EBT/receive/some-name. On machine B, there is a daemon that issues fuser on that file every few minutes, all day long. If it finds a process id and user id it goes to sleep. Now my question is will fuser (issued on machine a on the NFS mounted file) bring back the user-id and process id of the process that has the file open?
The only way fuser will find the processes that have the file open are if the fuser is run on the same machine as the process that has the file open. If the process is running on machine A and the file is on a file system that's actually located on and NFS shared from machine B, an fuser command run on machine B will not show the process on machine A.
There's lots of reasons why it works that way and for all practical purposes simply can't be made to work otherwise.
As for picking up incomplete files, the only one who can tell if the entire file has been sent is the sender. There's no way anyone receiving a file can tell if it's complete unless there's some passing of information in some way that indicates the file is complete.
One of the easiest ways is to have the sender rename the file from a name that indicates it's still being sent to a name that indicates that it's complete. Since a simple rename within one file system is an atomic operation on every sane file system, it's about the best way I know of to indicate that the file is completely sent.
Thanks so much for the help. You really helped my understand this issue much better. My work around is to monitor the growth of the file. When it no longer increases then the daemon moves forward with processing any files it finds.