check if file is open with lsof
I’m using linux mint 13 xfce and I have a file named wv.gold that I’m trying to check in bash if it’s open by any program (for instance, I opened it in sublime-text and gedit ) In many forums people say that if I run lsof | grep filename I should get 0 if it’s open or 256(1) if it’s closed, but in fact I get nothing (empty string) if I run using grep «wv.gold» , and get a little list if I do it using grep gold . The list is something like:
bash 2045 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir bash 2082 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir watch 4463 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir gedit 16679 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir lsof 20823 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir grep 20824 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir lsof 20825 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir Thus, I get the path to the directory it is but NOT the path to the file (there are other files there) and either way only to gedit process, not to sublime-text process. Is there some easy way to see if a txt file is opened by any other program? EDIT: It turns out (cf. comments from @mata and @ctn) that some editors load files and close them immediately, and they just reopen the file when saving it. This way, we can only see it when they are still opening a big file (since you have the time to observe it while opening) and it disappears immediately after that.
Is there a faster way to check if a file is in use?
I’m looking for a command line function or c function that will let me know if a file is open/in use by something. lsof and fuser do tell this, but they provide a lot of other info which results in taking up to 300ms in some situations (like when i use this code on MAC OS X, I’m devving for Linux and OS X) (I have a windows solution that takes 5ms so I’m trying to find something in Unix that also is very quick, and just returns true or false if file is in use)
2 Answers 2
If you are using this as a lock, it will not work as neither lsof or fuser prevent race conditions.
The basic process that lsof does is trawl through all processes /proc/*/fs looking for open file descriptors. This is going to take time no matter what you do.
You can do this yourself, but it is not likely to be any faster as you have to check for every open process on the system.
If what you are doing is time critical, figure out another way to do it.
- If you control the file through a program that you wrote; use a lock file.
- If you are running some command that operates on the file, look and see what documentation that command/program offers and see if it can’t make a lockfile. Failing that, see if it can’t make a file with its PID inside it. Then you can look at /proc//fs to see if your file is currently open or not. Looking at only one processes open file descriptors will be much faster then mapping across all of them.
- Otherwise in order to help you I am going to need more information about what you are doing.
You gave more information in a comment that you want to determine if Firefox is running on a given system. The best way to do this is to look for Firefox’s lock files. These are stored in default locations specified on the Mozilla wiki.
For example, on linux, have your program do the following:
- open up the ~/.mozilla/firefox/ directory.
- List all directories, filtering for directories ending in .default . (I think all profiles end with .default , if not just crawl into every directory.)
- In each directory above, look for the existence of a file named lock or .parentlock . If you see one or both files, Firefox is open.
This algorithm ought to execute faster than what you do on windows currently.
How to check if a file is opened in Linux?
The command lsof -t filename shows the IDs of all processes that have the particular file opened. lsof -t filename | wc -w gives you the number of processes currently accessing the file.
Solution 2
The fact that a file has been read into an editor like gedit does not mean that the file is still open. The editor most likely opens the file, reads its contents and then closes the file. After you have edited the file you have the choice to overwrite the existing file or save as another file.
Solution 3
You could (in addition of other answers) use the Linux-specific inotify(7) facilities.
I am understanding that you want to track one (or a few) particular given file, with a fixed file path (actually a given i-node). E.g. you would want to track when /var/run/foobar is accessed or modified, and do something when that happens
In particular, you might want to install and use incrond(8) and configure it thru incrontab(5)
If you want to run a script when some given file (on a native local, e.g. Ext4, BTRS, . but not NFS file system) is accessed or modified, use inotify incrond is exactly done for that purpose.
PS. AFAIK, inotify don’t work well for remote network files, e.g. NFS filesystems (in particular when another NFS client machine is modifying a file).
If the files you are fond of are somehow source files, you might be interested by revision control systems (like git) or builder systems (like GNU make); in a certain way these tools are related to file modification.
You could also have the particular file system sits in some FUSE filesystem, and write your own FUSE daemon.
If you can restrict and modify the programs accessing the file, you might want to use advisory locking, e.g. flock(2), lockf(3).
Perhaps the data sitting in the file should be in some database (e.g. sqlite or a real DBMS like PostGreSQL ou MongoDB). ACID properties are important .
Notice that the filesystem and the mount options may matter a lot.
You might want to use the stat(1) command.
It is difficult to help more without understanding the real use case and the motivation. You should avoid some XY problem
Probably, the workflow is wrong (having a shared file between several users able to write it), and you should approach the overall issue in some other way. For a pet project I would at least recommend using some advisory lock, and access & modify the information only thru your own programs (perhaps setuid) using flock (this excludes ordinary editors like gedit or commands like cat . ). However, your implicit use case seems to be well suited for a DBMS approach (a database does not have to contain a lot of data, it might be tiny), or some index locked file like GDBM library is handling.
Remember that on POSIX systems and Linux, several processes can access (and even modify) the same file simultaneously (unless you use some locking or synchronization).
Reading the Advanced Linux Programming book (freely available) would give you a broader picture (but it does not mention inotify which appeared aften the book was written).