Another mechanism or component programs and scripts often use is called a lock file. It’s usually temporary (it resides in /tmp) and is sometimes used when multiple entities rely on a single source of data or need to know that other programs exist. Sometimes, it’s merely the presence of a file, a particular timestamp on a file, or another simple artifact.

There are several ways to test for the existence of a file, but one important attribute that has not been demonstrated or explored is the concept of a hidden file. A hidden file in Linux is not really hidden (like in Windows), but it is not usually apparently unless a particular flag or command is ran. For example, the ls command does not return hidden files among the results, but the ls command with the -a flag will (-a for all).

Note:

Most file explorers have hidden files that aren’t visible by default. In Ubuntu, Ctrl + H inside of the file explorer toggles this feature.

To create a hidden file, a . (period) needs to be present at the beginning of a file’s name:

$ touch .myfirsthiddenfile.txt

Besides the presence of any regular file, we can also use the mktemp command to create lock files.

Prerequisites

We briefly mentioned that temporary files can reside inside the /tmp directory. Often, /tmp is home to short lived files such as lock files or information that can be volatile (destroyed on a power event without any detriment to the system). It is also usually RAM-based, which can offer performance benefits as well, especially if used as part of an inter-process communication system (more on this later in another recipe).

However, it is important to know that other programs can access your file in /tmp, so it should be secured with the sufficient permissions. It should also be given a name that is suitably random so that a filename collision does not occur.

Write Script:

Let’s start our activity as follows:

Open a new terminal and create a new script by the name of mylock.sh with the following contents:

mylock.sh

#!/bin.bash 
LOCKFILE="/tmp/mylock" 
function setup() { 
	# $$ will provide the process ID 
	TMPFILE="${LOCKFILE}.$$" 
	echo "$$" > "${TMPFILE}" 
	# Now we use hard links for atomic file operations 
	if ln "${TMPFILE}" "${LOCKFILE}" 2>&- ; then 
		echo "Created tmp lock" 
	else 
		echo "Locked by" $(<$LOCKFILE) 
		rm "${TMPFILE}" 
		exit 1 
	fi 
	trap "rm ${TMPFILE} ${LOCKFILE}" SIGINT SIGTERM SIGKILL 
} 
setup 
echo "Door was left unlocked" 
exit 0

Execute the script with the $ bash mylock.sh script and review the console’s output.

Next, we know that the script is looking for a particular lock file. What happens when we create a lock file and then re-run the script?

$ echo "1000" > /tmp/mylock $ bash mylock.sh $ rm /tmp/mylock $ bash mylock.sh

How Script works:

Let’s understand our script in detail:

The mylock.sh script reuses a couple of concepts that we are already familiar with: traps and symbolic links. We know that if a trap is called or rather, it catches a particular signal, it can clean up a lock file (as is the case in this script). Symbolic links are used since they can survive atomic operations over network file systems. If a file is present at the LOCKFILE location, then a lock is present. If the LOCKFILE is absent, the doors are open.

When we run mylock.sh, we will get the following because no lock file exists yet—including any temporary ones:

$ bash mylock.sh Created tmp lock Door was left unlocked

Since the preceding script exited correctly, the SIGKILL signal was handled and the temporary lockfile was removed. In this case, we want to create our own lockfiles that bypass this mechanism. Create a lockfile with a faux PID of 1000; running the script will return Locked by 1000, and upon deleting the lockfile, the regular behavior will occur once more (doors are unlocked).