in reply to How can i check my script is already running?

I would create a pid file that tells you whether your program is running. See File::Pid or File::Pid::Quick. You can also look at Highlander - allow only one invocation at a time of an expensive CGI script and RFC: A new module to help avoid running multiple instances of the same script (via cron, for example) for discussions.

Replies are listed 'Best First'.
Re^2: How can i check my script is already running?
by JavaFan (Canon) on May 11, 2010 at 10:16 UTC
    I would create a pid file that tells you whether your program is running.
    There are two possible problems with that: it can generate false positives, and false negatives. If the pid file is removed for some reason, a next invocation can falsely determine no other invocation is running. OTOH, if an invocation dies unexpectedly, it may leave behind the pid file. By the time the program is invoked again, the pid may have been reused; the program would falsely determine there's another invocation, when there isn't. On top of that, to avoid race conditions, only one invocation should be able to modify the pid file at a time. But that means, in order to solve the problem (only one invocation at a time), you first have to solve the problem (only one invocation at a time accessing the pid file). You'd have to use file locks. But then you may as well use file locks in the first place.

    I'd only use a pid file if there's a benefit in knowing the pid of the running instance.

[reply]
      If the pid file is removed for some reason, a next invocation can falsely determine no other invocation is running. OTOH, if an invocation dies unexpectedly, it may leave behind the pid file.
      If the pid contained in the pid lock file is not in the process table, you should display a message asking if the process is running. If not, you can prompt the user to remove the file.

      If the file does not exist (false negative), there is a logic error in your program (the pid lock file should be the first object created and the last destroyed).

      You'd have to use file locks. But then you may as well use file locks in the first place.
      The point of using a predictable lock file (program_name.pid) in a predictable location (/var/run ?) is to handle all of the situations you describe. Data files used by the program may or may not be predictable. Directory locations may or may not be predictable (relative vs. absolute paths).

      Using the conventions that have grown over the years (/var/run for pid lock files) work for a reason. YMMV

[reply]
        If the pid file is removed for some reason, a next invocation can falsely determine no other invocation is running. OTOH, if an invocation dies unexpectedly, it may leave behind the pid file.
        If the pid contained in the pid lock file is not in the process table, you should display a message asking if the process is running. If not, you can prompt the user to remove the file.
        Yes, but that's an if. And you conveniently left off the next line:
        By the time the program is invoked again, the pid may have been reused;
        So, we now have a pid file, with the pid it contains in the process table. Now what?
        If the file does not exist (false negative), there is a logic error in your program (the pid lock file should be the first object created and the last destroyed).
        I'm sure you are aware there are OSses that allow processes to remove files they haven't written to. I'm unware of any programming technique that prevents other processes (for instance, sometime typing 'rm file') from removing files. Please enlighten us, so we never have to make such logical errors in our programs again!
        The point of using a predictable lock file (program_name.pid) in a predictable location (/var/run ?) is to handle all of the situations you describe. Data files used by the program may or may not be predictable.
        Hmmm, a pid file is a data file. It contains data, doesn't? Data you're using to determine whether an instance is running or not.
        Using the conventions that have grown over the years (/var/run for pid lock files) work for a reason. YMMV
        I've been around long enough to know that while pid files often work, they sometimes don't. For the reasons I explained. You've never had to remove a pidfile to allow a program to start? Get some more experience.
[reply]

In Section Seekers of Perl Wisdom