The database .lk file

How Progress uses the database lock file ( .lk )
What is the .lk file used for ?
Why is the database .lk file so important?
 

The database lock file (.lk) is the only protection against multiple processes opening the database or the client accessing the wrong database. 

Associated Error messages:
WHAT'S IN THE DATABASE LOCK FILE?

The .lk file contains three pieces of information:

1. The mode in which the database was started - Single user or Multi-user database start up mode 
2. The process id (pid) of the process that started the database - PID of the Broker or user process if in single user mode.
3. The hostname where the process that started it is running - The host name verifies if the process id is on the same system or a different machine that has the same filesystem mounted where the .lk file resides

This information can be extracted from a copy. The database .lk file should never be interrogated when the database is in use:

•  Extracting the OpenEdge database process id from the .lk lock file  

HOW DOES OPENEDGE USE .LK FILE INFORMATION?

The .lk file is used to determine if the database is currently in use. When a process attempts to start a database it first tests for the existence of a .lk file:

A.  If there is no .lk file, the process creates one and starts up the database.
B.  When a .lk file already exists, the process reads these three values to determine if it is a valid .lk file. This determination is performed as follows:

1. The process tests to see if it can run the gethostname() call. This should return the same information as a uname -n command. If this call fails, i.e. the gethostname() returned NULL, then no determination can be made about the .lk file, so we assume it is valid. Go to Step 6.
2. Check if the hostname returned by the gethostname() call matches the hostname stored in the .lk file. If it does not match, then no determination can be made about the .lk file, so we assume it is valid. Go to step 6.
3. If the hostname matches (that is, we are on the same host that is in the .lk file), check if the pid stored in the .lk file is an active pid on the system.
4. If the pid is not active, then the .lk file is not valid, so we remove the existing .lk file, create a new one and startup the database.
5. If the pid is active, then the .lk file is valid and we cannot startup the database.
6. If the .lk file is valid, then we cannot startup the database and we return a message appropriate to the mode entry in the .lk file.
7. If the .lk file is determined to not be valid, then we remove the existing .lk file, create a new one, and startup the database.

While the database .lk file is used to determine if the database is currently in use, the watchdog uses the 'dbname.lk' file to protect the database from having multiple processes writing to it when they shouldn't. For further information refer to Article:

•  What does the Progress Watchdog do 
•  What causes ".lk is missing, shutting down 4195  

Cautionary Notes:

1.  There is a known issue that has been in the Progress database for a long time where offline procopy | prodb execution does not put a .lk file on the source database during execution. 

When another user/process connects to the source database while the database copy is still running, the resulting target database will be corrupted.  

•  Can using PROCOPY and PROUTIL -C BUSY result in a corrupted target database?  

2. Using PROUTIL to determine the current database status is not always reliable:

•  PROUTIL -C HOLDER or BUSY incorrectly shows db as running after a server reboot  

3.  Never take deleting the .lk file lightly

It is the only protection that exists to prevent multiple processes starting the database. When there has been some type of abnormal shutdown of the database due to system failure and the .lk is not properly removed, only once it has been determined that there are no progress processes accessing the database, then the .lk file can be deleted.  This action is critical and should not be taken lightly and definitely not scripted.

There are better options like using "truncate bi" to access the database after a system crash instead of immediately trying to start the database multi-user again or running "prostrct repair". Consequences of not dealing properly with an existing database lk file have been recorded from customer case investigations in the following Articles:

•  Single user database telnet session network failure causes multi-user shutdown  
•  BI Timestamp mismatch after removing database .lk file and starting a second session against database while first session is still running.  
•  Shared Memory client connects to the wrong database after power failure or abnormal shutdown   
•  Cannot start database due to corruption of database after .lk file is intentionally removed.