Solaris doesn't lock open files automatically (not just Solaris - most of *nix operating systems behave this way).

In general, when a process is about to update a file, the process is responsible for checking existing locks on target file, acquiring a lock and releasing it after updating the file. However given that not all processes cooperate and adhere to this mechanism (advisory locking) due to various reasons, such non-conforming practice may lead to problems such as inconsistent or invalid data mainly triggered by race condition(s). Serialization is one possible solution to prevent this, where only one process is allowed to update the target file at any time. It can be achieved with the help of file locking mechanism on Solaris as well as majority of other operating systems.

On Solaris, a file can be locked for exclusive access by any process with the help of fcntl() system call. fcntl() function provides for control over open files. It can be used for finer-grained control over the locking -- for instance, we can specify whether or not to make the call block while requesting exclusive or shared lock.

The following rudimentary Python code demonstrates how to acquire an exclusive lock on a file that makes all other processes wait to get access to the file in focus.

eg.,

% cat -n xflock.py
     1  #!/bin/python
     2  import fcntl, time
     3  f = open('somefile', 'a')
     4  print 'waiting for exclusive lock'
     5  fcntl.flock(f, fcntl.LOCK_EX)
     6  print 'acquired lock at %s' % time.strftime('%Y-%m-%d %H:%M:%S')
     7  time.sleep(10)
     8  f.close()
     9  print 'released lock at %s' % time.strftime('%Y-%m-%d %H:%M:%S')

Running the above code in two terminal windows at the same time shows the following.

Terminal 1:

% ./xflock.py
waiting for exclusive lock
acquired lock at 2018-06-30 22:25:36
released lock at 2018-06-30 22:25:46

Terminal 2:

% ./xflock.py
waiting for exclusive lock
acquired lock at 2018-06-30 22:25:46
released lock at 2018-06-30 22:25:56

Notice that the process running in second terminal was blocked waiting to acquire the lock until the process running in first terminal released the exclusive lock.

Non-Blocking Attempt

If the requirement is not to block on exclusive lock acquisition, it can be achieved with LOCK_EX (acquire exclusive lock) and LOCK_NB (do not block when locking) operations by performing a bitwise OR on them. In other words, the statement fcntl.flock(f, fcntl.LOCK_EX) becomes fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB) so the process will either get the lock or move on without blocking.

Be aware that an IOError will be raised when a lock cannot be acquired in non-blocking mode. Therefore, it is the responsibility of the application developer to catch the exception and properly deal with the situation.

The behavior changes as shown below after the inclusion of fcntl.LOCK_NB in the sample code above.

Terminal 1:

% ./xflock.py
waiting for exclusive lock
acquired lock at 2018-06-30 22:42:34
released lock at 2018-06-30 22:42:44

Terminal 2:

% ./xflock.py
waiting for exclusive lock
Traceback (most recent call last):
  File "./xflock.py", line 5, in 
    fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
IOError: [Errno 11] Resource temporarily unavailable

Labels: solaris exclusive+locks file+locking python fcntl *nix

Posted by: Giri Mandalika.    # 11:17 PM Tweet