is valid first check if the file exists, then open it and read the pid, then "kill -0 $pid" (send a no-op signal to the process) to see if it's still running. If the process is dead, they delete the lockfile and try to create a new one. If you don't enable "-stale=&gt;1", the LockFile library will just abort if the file exists at all. This means your system will require manual intervention if the locking process ever dies suddenly (eg. by "kill -9" or if your system crashes), which is no fun. The next option, "-hold=&gt;0", disables a trojan horse extremely evil option that is enabled automatically when you set "-stale=&gt;1". The "-hold" option sets the maximum time a lock can be held before being considered stale . The default is 3600 seconds (one hour). Now, this sounds like it might be a useful feature: after all, you don't want to let a lock file just hang around forever, right? No! No! It's a terrible idea! If the "kill -0 $pid" test works, then you know the guy who created the lock is still around. Why on earth would you then consider it stale, forcibly remove the lock, and start doing your own thing? That's a course that's pretty much guaranteed to get you into trouble, if you consider that you've probably created the lockfile for a reason. So we set "-hold=&gt;0" to disable this amazing feature. The only way we want to break a stale lock is if