I often see that programs specify pid and lock files. And I'm not quite sure what they do.
For example, when compiling nginx:
--pid-path=/var/run/nginx.pid \ --lock-path=/var/lock/nginx.lock \
Can somebody shed some light on this one?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
pid files are written by some programs to record their process ID while they are starting. This has multiple purposes:
killcommand if one wants to end it.
Mere presence of a pid file doesn't guarantee that that particular process id is running, of course, so this method isn't 100% foolproof but "good enough" in a lot of instances. Checking if a particular PID exists in the process table isn't totally portable across UNIX-like operating systems unless you want to depend on the
ps utility, which may not be desirable to call in all instances (and I believe some UNIX-like operating systems implement
ps differently anyway).
The idea with lock files is the following: the purpose is for two (well-behaved) separate instances of a program, which may be running concurrently on one system, don't access something else at the same time. The idea is before the program accesses its resource, it checks for presence of a lock file, and if the lock file exists, either error out or wait for it to go away. When it doesn't exist, the program wanting to "acquire" the resource creates the file, and then other instances that might come across later will wait for this process to be done with it. Of course, this assumes the program "acquiring" the lock does in fact release it and doesn't forget to delete the lock file.
This works because the filesystem under all UNIX-like operating systems enforces serialization, which means only one change to the filesystem actually happens at any given time. Sort of like locks with databases and such.
Operating systems or runtime platforms typically offer synchronization primitives and it's usually a better decision to use those instead. There may be situations such as writing something that's meant to run on a wide variety of operating systems past and future without a reliable library to abstract the calls (such as possibly
bash based scripts meant to work in a wide variety of unix flavors) - in that case this scheme may be a good compromise.
These files are often used by daemons that should only be run once on a system. The PID file usually contains the process ID number of the already launched and running program if one exists. Also, when it starts up, it creates the lock file. As long as the lock file exists, it won't start another one without user intervention. If the lock file exists and the process id mentioned in the pid file isn't running, the daemon is considered to be in a "dead" state, meaning it's supposed to be running but isn't probably due to a crash or improper shutdown. This might initiate a special startup / restart scenario for some programs. Properly shutting it down will remove the lock file.
A PID file will contain the Process ID of a running process. This has various uses; you can read it and check that the process is still running and take appropriate action or read it and kill the process.
A lock file is most likely application specific. Lock files are used to indicate that some resource is in use and that the process wanting access should wait until the resource is freed before continuing.