Yes, that can in principle cause a problem.

You can try to mitigate it - if you read the pid and find that it is not your own, you can check if that pid is still a running process, and scream bloody murder if it is not. If it is a running process, in some circumstances you can go further and check if it is a process that could legitimately be locking the pid file, and scream bloody murder if not.

What you want to do in that situation is always going to depend on your particular context.

In particular it is going to depend on why you are locking. If you are locking access to a resource because you're going to modify it in a way that leaves it invalid/unstable until you are done, then a failure leaves you problems to resolve other than simply being locked out.

But over many years, I have found that it is pretty rare that a pid file gets left locked due to a failure. And, just speaking of my own experience, it has been exceedingly rare that a locked pid file actually caused a problem - most commonly, you try to do something and see an error message "can't do that, the pid file is locked". And then you remember that the machine just crashed while you were running a similar command a few minutes ago, so you check for breakage, remove the lock file, and continue with your day.

Maybe I (got real lucky|had excellent judgement) in using a pid file only in situations where failures tended not to cause major problems. Your particular context will determine what the effect will be - whether it will be immediately visible to a human, how easy it is to check for breakage and fix it.

But if you can get the basics right, a pid file can be a pretty straightforward mechanism that works well enough to solve a particular problem.

In reply to Re^6: Mechanism for ensuring only one instance of a Perl script can only run? by hv
in thread Mechanism for ensuring only one instance of a Perl script can only run? by redapplesonly

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.