I see a lot of programs that does write a pidfile, and check at boot its existence. And this is good. But many application does not start even if they check that the pidfile exists, yes, but no process with that pid is running.

Why this behavior? Is it not more simple to remove the pidfile and warn the user, at most?


The proper procedure is to check for the existence of the pidfile and, if it exists, verify that the pid inside does not refer to a current process. If there is no process with the pid, then the pidfile should be re-created with the pid of the current process. If the process that created the pidfile has not exited cleanly (i.e. has become a "zombie" process) or the pid has been re-used (unlikely) then the new process will exit. Are you sure the process is exiting because the pidfile exists, or could it possibly be some other reason (the failing process may have left the environment in an invalid state)?

  • 1
    WTF. Is that approach really considered proper? The chance of reused PID seems non-negligible to me. – CodesInChaos May 6 '16 at 16:47
  • If you've got so much pid churn that you're re-using them often, then they're probably pretty short lived, so the window for a collision is fairly low. It would also be easy to add an additional check if the pid is in use to verify that the process is running the same program, although I don't recall ever seeing that used. – TMN May 6 '16 at 16:58
  • @CodesInChaos, using Big Sky Theory on a 15-bit number space, yay! – Erik Eidt May 6 '16 at 19:10
  • And this is how I'll implement it, but I see a lot of programs that does not check if a process with that pid is running, they simply exit. See Tomcat or Postfix for example. – Marco Sulla May 9 '16 at 7:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.