Optimal lock file method

Question

Windows has an option to open a file with exclusive access rights. Unix doesn't.

In order to ensure exclusive access to some file or device, it is common practice in Unix to use a lock file usually stored in the /var/lock directory.

The C instruction open( "/var/lock/myLock.lock", O_RDWR | O_CREAT | O_EXCL, 0666 ) returns -1 if the lock file already exist, otherwise it creates it. The function is atomic and ensures there is not race condition.

When the resource is released, the lock file is deleted by the following instruction remove( "/var/lock/myLock.lock" ).

There are two problems with this method.

1. The program may terminate without removing the lock. For instance because it is killed, crashes or whatever. The lock file remains in place, and will prevent any access to the resource even though it is not used anymore.

2. The lock file is created with group and world write privilege but it is a common practice to configure accounts to use a permission mask that will clear the group and world write permission. Thus, if we had a reliable method to determine that the lock is orphan (not use), a user not owner of the file will not be allowed to remove it.

For the record, I use the lock file to ensure exclusive access to the device connected to the serial port (/dev/ttyUSBx in fact). Advisory method, requiring cooperation, is OK. But exclusive access should be ensured between different users.

Is there a better synchronization method than the lock file? How to determine if the process who created the lock file is still running? How to make it possible for another user to remove the lock file if not in use?

One solution I came up with was to use the file as Unix socket file. If the file exist, try to connect using the file. If it fails, we may assume the owner process of the file is dead. This requires to have a thread looping on socket accept() in the owner process. Unfortunately, the system wouldn't be atomic anymore.

Answer 1

Take a look at the enlightening presentation File Locking Tricks and Traps:

This short talk presents several common pitfalls of file locking and a few useful tricks for using file locking more effectively.

Edit: To address your questions more precisely:

Is there a better synchronization method than the lock file?

As @Hasturkun already mentioned and as the presentation above told, the system call you need to use is flock(2). If the resource you'd like to share across many users is already file-based (in your case it is /dev/ttyUSBx), then you can flock the device file itself.

How to determine if the process who created the lock file is still running?

You don't have to determine this, as the flock-ed lock will be automatically released upon closing the file descriptor associated with your file, even if the process was terminated.

How making it possible for another user to remove the lock file if not in use?

If you would lock the device file itself, then there will be no need to remove the file. Even if you would decide to lock an ordinary file in /var/lock, with flock you will not need to remove the file in order to release the lock.