Who locked that file?

I can't even imagine how many times I've heard someone complain about a locked file. Sometimes it's simple - the call goes out "Who has record 758 open?" or something like that, and sure enough, Bill forgot he was working on that, closes it out and all is well. But other times it is not simple, and a system admin has to track down who is doing what.

Note that in this post we're talking about real locking - not a volume that can't be ejected (Mac speak) or a file system that can't be unmounted (the rest of us). For that, just use "lsof" to find out what process is stopping you.

I had a customer call today with the locking problem: "How can we tell if a user has a lock on a file in our application?". I immediately thought of "lsof", because the man page says it should display locking information. It does so on several Linux systems I tested, but does not show that on my Mac.

For testing purposes, we'll need something that locks a file. This very simple C program does that. Note that there is no error checking at all here; it just assumes success on everything. Be sure to "touch mylockedfile" before using this.

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>

main() {
int fd;
struct flock lock;
lock.l_type=F_WRLCK;
lock.l_start=0;
lock.l_whence=0;
lock.l_len=2;

fd=open("mylockedfile", O_WRONLY,S_IWUSR );
printf("%d\n",fcntl(fd,F_SETLK,&lock));
getchar();
}
 

All that does is apply a lock to a few bytes of "mylocked" file. It sits and waits for you to press enter, and then teminates. Locks are removed upon process termination, so pressing enter ends everything cleanly.

If you called that program "makelock.c", then "make makelock" should compile it and "touch mylockedfile;./makelock" should set it running. You should see this:

open 3
lock 0

If you saw "-1" for either of those, something did not work, and I'm not going to take the space here to try to help you figure out what you did wrong - probably permissions.

In another screen, type "lsof mylockedfile". On a Linux system, you should see something like this:

COMMAND        PID USER   FD   TYPE DEVICE SIZE    NODE NAME
makelock      6386 tonyl    3ww  REG    3,2    0 2785316 mylockedfile
 

It's the extra "w" that indicates the lock. If you simply had the file open, there would only be one "w". OK, that's nice, and it certainly wouldn't be hard to wrap a shell script around lsof to find the offending user. But unfortunately, on Mac OS X Leopard, lsof can't seem to spot the lock:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
makelock      3331  apl    3w   REG   14,2        0 9714583 mylockedfile
 

That doesn't help. And if we don't have root access, "lsof" won't help anyway.

Fortunately it's easy to write a little C program that tests for other processes locking files. Again, this program has no error checking; you'd want to dress it up much more for a production tool, but the raw basics are this:

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>

main() {
int fd;
struct flock lock;
lock.l_type=F_WRLCK;
lock.l_start=0;
lock.l_whence=0;
lock.l_len=0;

printf("open %d\n",fd=open("mylockedfile", O_RDONLY ));
printf("lock %d\n",fcntl(fd,F_GETLK,&lock));
if (lock.l_type == F_UNLCK) {
  printf("%d\n",0);
  return(0);
}
 printf("%d\n",lock.l_pid);
 return(lock.l_pid);

}
 

With "makelock" running, type "make testlock && ./testlock" and it should return the process id of "makelock".

This "testlock" tries to lock the entire file. If you modified it so that it had "lock.l_start=3;" and recompiled it, it would report 0, meaning no lock (because "makelock" only locks the first two bytes).

So, if you can use "lsof" in a shell script, that's an easy way to find the responsible PID, but if you can't, something like this certainly can. By the way, on Linux, there's also /proc/locks, which does show all file locks, but you'd need to grep inode numbers from it:

1: POSIX  ADVISORY  WRITE 6641 03:02:4014117 0 1 d7693680 c0281850 d76934b8 00000000 d769368c
 

The "6641" after "WRITE is the PID, and the "4014117" is the inode. That's a bit more difficult than using "lsof" or this program, but everything you need is there. The "03:02" is the major-device:minor-device of the partition that has the file (/dev/hda2 in this case), the rest of it has to do with the region locked, which you probably don't care about for this purpose.

If you didn't understand any of this, I suggest you read at least Writing and Compiling C programs on Linux. If you think I just plucked those programs out of thin air and my prodigious memory, well, that's pretty funny, but really I did what I always do: cracked open my copy of Steven's Advanced Programming in the Unix Environment and cribbed what I needed.

1 comment

More Articles by Anthony Lawrence - Find me on Google+

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.