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?

3 Answers 3


pid files are written by some programs to record their process ID while they are starting. This has multiple purposes:

  • It's a signal to other processes and users of the system that that particular program is running, or at least started successfully.
  • It allows one to write a script really easy to check if it's running and issue a plain kill command if one wants to end it.
  • It's a cheap way for a program to see if a previous running instance of it did not exit successfully.

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 sh or bash based scripts meant to work in a wide variety of unix flavors) - in that case this scheme may be a good compromise.

  • 1
    So if the program "acquiring" the lock crashes and doesn't delete the lock file, then the other program will never be able to access the resources. Is that right?
    – CodeBlue
    Commented Jun 10, 2014 at 15:16
  • 2
    This is correct, unless the lock file is manually deleted. VMWare Player exhibits this behaivor, for example, if VMWare Player crashes, you have to delete a .lck file in the VM's directory otherwise it will tell you it's in use when you try to start it.
    – LawrenceC
    Commented Jun 11, 2014 at 14:04
  • 1
    What about Windows? How does it handle .lock files? After all, it's not Unix-like. Commented Sep 15, 2015 at 21:32
  • 2
    I don't think it's common for Windows programs to work this way. The only programs with this behavior that I've seen are ports from Unix/Linux
    – HaMster
    Commented Feb 23, 2016 at 12:20
  • 4
    LawrenceC, Re "When it doesn't exist, the program wanting to "acquire" the resource creates the file"; But there are proper functions specifically built to do such synchronization. Why not rely on those functions instead of using the "file hack"?
    – Pacerier
    Commented Apr 15, 2016 at 15:26

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.

  • 1
    +1 Explaining the use of having both the lock file and the pid file.
    – Kyle Krull
    Commented Oct 6, 2015 at 2:00
  • 2
    @Caleb - Please explain why both a PID file and a lock file would be used. It seems a PID file would be sufficient. If the PID file exists, the PID could be checked to see if the process is running, just takes less steps than check for a lockfile, checking for a PID file, and then verifying the existence of the process.
    – MVaughan
    Commented Jan 25, 2017 at 16:57
  • 2
    @MVaughan To avoid race conditions if nothing else. Some apps have uses for times when the still need the PID but can relinquish the lock. But at a more fundamental level if you overload one file for both operations you open the door to failures such as a crash leaving an inconsistent state on the system.
    – Caleb
    Commented Jan 25, 2017 at 21:06

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .