How to stock PID of lockfile command in Linux
I am using lockfile command in linux to manage access to a special file. When my principal script crashes for some reason, i finish having hanging locks that prevent any new launch of the principal script and bother heavily its execution. Is there a way to stock the PID of my lockfile processes so i can track them and make proper clean-up before relaunching my principal script. Hope i was clear enough.
1 Answer 1
This is a fragile mechanism. I prefer to use real file locks, so when the process that owns them dies, the O/S will release the lock automatically. Easy to do in perl (using the flock function), but i don’t know if it’s possible in Bash.
More to the point, i suppose you could use the lockfile itself to hold the PID of the script holding the lock, right?
(I don’t do shell scripting much. i think the code below is mostly right, but use at your own risk. There are race conditions.)
while [[ lockfile -! -r 0 lock.file ]] do kill -0 `cat lock.file` if [[ $? -ne 0 ]] then # process doesn't exist anymore echo $$ >lock.file # do something important rm -f lock.file break fi sleep 5 done while [[ true ]] do if [[ ! -e pid.file ]] then echo $$ > pid.file else if [[ kill -0 `cat pid.file`]] then # owner process exists sleep 30 else # process gone, take ownership echo $$ > pid.file # ### DO SOMETHING IMPORTANT HERE ### rm -f pid.file break fi fi done I like the second one better. It’s still far from perfect (lots of race conditions), but it might work if there aren’t too many processes fighting for the lock. Also, the sleep 30 should include some randomness in it, if possible (the length of the sleep should have a random component).
But see here, it looks like you can use flock with some versions of the shell. This would be similar to what i do in perl, and it would be safer than the althernatives i can think of.
What are pid and lock files for?
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 \ 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.
Reference for proper handling of PID file on Unix
Where can I find a well-respected reference that details the proper handling of PID files on Unix? On Unix operating systems, it is common practice to “lock” a program (often a daemon) by use of a special lock file: the PID file. This is a file in a predictable location, often ‘/var/run/foo.pid’. The program is supposed to check when it starts up whether the PID file exists and, if the file does exist, exit with an error. So it’s a kind of advisory, collaborative locking mechanism. The file contains a single line of text, being the numeric process ID (hence the name “PID file”) of the process that currently holds the lock; this allows an easy way to automate sending a signal to the process that holds the lock. What I can’t find is a good reference on expected or “best practice” behaviour for handling PID files. There are various nuances: how to actually lock the file (don’t bother? use the kernel? what about platform incompatibilities?), handling stale locks (silently delete them? when to check?), when exactly to acquire and release the lock, and so forth. Where can I find a respected, most-authoritative reference (ideally on the level of W. Richard Stevens) for this small topic?
5 Answers 5
First off, on all modern UNIXes /var/run does not persist across reboots.
The general method of handling the PID file is to create it during initialization and delete it from any exit, either normal or signal handler.
There are two canonical ways to atomically create/check for the file. The main one these days is to open it with the O_EXCL flag: if the file already exists, the call fails. The old way (mandatory on systems without O_EXCL ) is to create it with a random name and link to it. The link will fail if the target exists.
“There are two canonical ways to atomically create/check for the file.” That’s exactly the kind of thing my question is about: where is this canon recorded canonically, and what makes it authoritative compared to conflicting advice from others?
Unfortunately much of UNIX operation methods is handed down in the culture. Reading the man pages for the system calls described in POSIX.1 (these are, confusingly enough, in man section 2) reveals only a few things that are suitable for locking. Since flock() isn’t trusted this leaves only these two and one involving mkdir.
A fair question is «Why isn’t flock() trusted.» The answer is there have been too many broken systems over the years, and it never works correctly over nfs anyway (the nfslock protocol itself is subject to the split mind problem).