>So I’ve had some issues with duplicate processes running and that kind of confused me. I looked in the code and I’m using Proc::Pid::File to control the processes and exiting out if the old process is still running. I finally found some time to dig into this further late last week. It seems that the logic the module currently has you use is essentially:
The problem here is that there is a race condition between the checking for alive and updating the pid file to take control. What is happening on our system is:
process1: is pidAlive? no.
process2: is pidAlive? no.
process1: update pidFile.
process2: update pidFile.
Now both process1 and process2 are running, the pid file reflects process2 is alive, nothing indicates that process1 is alive, so if the restart or shutdown systems are used, they talk to process2 but process1 keeps on trucking. At this point process3 can check the pid and it’s not alive so it will go ahead and start up perpetuating the problem.
What is really needed would be a single method that will eliminate the race condition:
create pid file if it does not exist
exclusive lock pid file
if pid and pid is running then
result is false
result is true
update pid file to our pid
release exclusive lock
The problem with this solution? Proc::Pid::File has been around for quite a while and a lot of people are using it. We can’t just change the API like that. We need to find a way to keep the same API, but change the logic to match what I’ve proposed.
I’ll need to give this some more thought on how to work around this without changing the API. Perhaps it’s just continue to support the current API, and add a new method to do both at once but do it cleanly instead of just using it as a wrapper to call both in sequence.