How to list processes locking file?
Using flock , several processes can have a shared lock at the same time, or be waiting to acquire a write lock. How do I get a list of these processes? That is, for a given file X, ideally to find the process id of each process which either holds, or is waiting for, a lock on the file. It would be a very good start though just to get a count of the number of processes waiting for a lock.
4 Answers 4
lslocks , from the util-linux package, does exactly this.
In the MODE column, processes waiting for a lock will be marked with a * .
Apt-cache says that util-linux is already the newest version (2.20.1-1ubuntu3), but I don’t have lslocks; is there a repo I can use that will give me it?
Looks like this was added in 2.22, so Ubuntu’s version is too old. Presumably a new version will be available eventually. (This is also the case with RHEL 6 or CentOS.) You could build it yourself, or you could use the lsof approach Joel Davis suggests.
lslocks reads /proc/locks , in a pinch you can read that directly yourself, with the caveat that files are identified by device and inode rather than name. Since you know the file, that ought not be a problem. Blocked entries have a -> prefix before the lock type column (thus adding a column to that line).
in my case lslocks showed that the file was locked by a PID that did not exist. But lsof pointed out the true culprit, an instance of ssh-agent ¯\_(ツ)_/¯ it probably got in when I tried flock -c that launched a shell..
Two possibilities: lsof (my preference) or lslk (specifically for file locks):
[root@policyServer ~]# lslk | grep "master.lock" SRC PID DEV INUM SZ TY M ST WH END LEN NAME master 1650 253,0 12423 33 w 0 0 0 0 0 /var/lib/postfix/master.lock [root@policyServer ~]# lsof | grep "master.lock" master 1650 root 10uW REG 253,0 33 12423 /var/lib/postfix/master.lock Output of lslk is self-expanatory but lsof puts the lock description in the «FD» column (which is 10uW above). From the man page:
The mode character is followed by one of these lock characters, describing the type of lock applied to the file: N for a Solaris NFS lock of unknown type; r for read lock on part of the file; R for a read lock on the entire file; w for a write lock on part of the file; W for a write lock on the entire file; u for a read and write lock of any length; U for a lock of unknown type; x for an SCO OpenServer Xenix lock on part of the file; X for an SCO OpenServer Xenix lock on the entire file; space if there is no lock. So the «FD» column of lsof above breaks down to:
10 The literal descriptor of this open file. What’s linked to by /proc/1650/fd/10
u File is open for reading and writing
W program has a write lock on the file.
PHP read lock file created by a different Linux user?
Jobby is a PHP cron management script that creates a lock file at /tmp/xxxxx.lck for each job / process that’s been started.
Before Rob came in, Jim used to do all the stuff including both the central framework AND the specific work. Therefore the cron script will be run as Jim and the lock file will be created and owned by Jim thus the script reads the lock file no problem.
However, when Rob came in and took over the specific work, the cron script by Rob is run as Rob which calls the Jobby library owned by Jim. The lock file is thus created and owned by Jim. Now the cron script by Rob can’t read the lock file created by Jim and keeps giving the Jobby error:
ERROR: Unable to open file (File: /tmp/xxxx.lck).
Basically, script A (Rob) calls script B (Jim) which creates /tmp/xxxx.lck (-rw-r—r— 1 Jim Jim), is there any secure way to make script A (Rob) able to read /tmp/xxxx.lck?
But ain’t the permissions (-rw-r—r—) all right since it allows anyone to read the file? That’s really odd.
Then why is Jobby giving this error?
Update
It occurs to me when I’m writing this question that I should find out why Jobby is throwing this error in the first place. And I found this:
public function acquireLock($lockfile) < if (array_key_exists($lockfile, $this->lockHandles)) < throw new Exception("Lock already acquired (Lockfile: $lockfile)."); >if (!file_exists($lockfile) && !touch($lockfile)) < throw new Exception("Unable to create file (File: $lockfile)."); >$fh = fopen($lockfile, "r+"); if ($fh === false) < throw new Exception("Unable to open file (File: $lockfile)."); >$attempts = 5; while ($attempts > 0) < if (flock($fh, LOCK_EX | LOCK_NB)) < $this->lockHandles[$lockfile] = $fh; ftruncate($fh, 0); fwrite($fh, getmypid()); return; > usleep(250); --$attempts; > throw new InfoException("Job is still locked (Lockfile: $lockfile)!"); > So it is asking for both reading and writing permissions of the lock file.
Since the lock file is (-rw-r—r— 1 Jim Jim) script of Rob won’t be able to write to it — I guess this is the problem?
But why does Jobby creates the file as Jim but opens it as Rob?
Is there any way I can make it both creates and then opens the file as Rob?
Obtain exclusive read/write lock on a file for atomic updates
I want to have a file that is used as a counter. User A will write and increment this number, while User B requests to read the file. Is it possible that User A can lock this file so no one can read or write to it until User A’s write is finished? I’ve looked into flock but can’t seem to get it to work as I expect it.
flock -x -w 5 /dev/shm/counter.txt echo "4" > /dev/shm/counter.txt && sleep 5 If there’s a more appropriate way to get this atomic-like incrementing file that’d be great to hear too! My goal is:
LOCK counter.txt; write to counter.txt; Read counter.txt; realize it's locked so wait until that lock is finished. I’m sure I’m using it incorrectly, but while using the code above I can use two shells and have them both edit the counter file while I thought one was locking it. So if I run that line twice on two separate shells, (each with its own number to echo), I still see the second number being written
When the first completes and releases its lock, the second runs. Isn’t that the way it should work? (In the code above, && sleep 5 is executed after the flock releases the lock.)
Hmm intersting. So in that case it would have been too quick for my human eye to catch. Great! My next challenge is how to put multiple commands in flock , but I’ll put that as a separate question. Thanks John!
3 Answers 3
File locks aren’t mandatory 1 — i.e., you can’t lock a file so that another process cannot access it. Locking a file means that if a(nother) process checks to see if it has been locked, it will know.
The purpose of flock is to do stuff like what you want, but you must then use flock for each and every attempted access. Keep in mind those are blocking calls; from man flock :
if the lock cannot be immediately acquired, flock waits until the lock is available
1. Which makes the feature seem useless if you are using it for, e.g., security, but that is not the purpose of file locks — they’re for synchronization, which is what you are doing. User Leo pointed out that there may be a non standardized implementation of mandatory file locking in the linux kernel (see this discussion), based on historical parallels from other *nix operating systems. However, this looks to be a C level interface only.