Locking out a CGI script whilst it runs

[heezy]

Hi

I have a CGI script that trundles through a huge directory of pdf files and retitles them based on values in a mySQL database. As it runs it outputs the old and new titles of the pdf's to the users browser. This takes approx 15 mins to complete

At the moment it is possible for more than one person to run the script at a time as all they have to do is point their browser in the right direction.

Does anyone have a cunning Perl-ish way of locking out the script so that it can only be run by one person at a time?

I thought of using a flag in a config file for the script but this could cause problems if the user clicked stop on their browser and the first invocation of the script never finishes (i.e. never releases the lock)

Ideas on this would be a great help

thanks all,

m

[merlyn]

As I've said frequently, I have a column on exactly that.

Since your application takes a long time, you might want to try the approach in my "watch long processes" CGI column as well. In fact, that'd be neat, because the second guy coming along would simply watch the result along with the first guy. Cool. In fact, that could be another column. {grin}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

[steves]

I'd have to agree with the "why CGI" question, but that aside, I've done this with PID files. The file serves as a lock; if another instance tries to run the contents are looked at to see if the PID is actually running.

The caveat here is that I did not use Proc::PID::File as most people do. I wrote mine years ago before that existed or before I knew it existed so I don't know if it handles that as mine does. I open the file like this to (I think) allow only one process at a time to get at it. I should review this now that I know more. 8-)

  
local *PID_FH;
sysopen(PID_FH, $file, O_RDWR | O_CREAT) or die
  "Can't open PID file $file: $!\n";

flock(PID_FH, LOCK_EX) or die
  "Can't get write lock on PID file $file: $!\n";

[Ryszard]

Use a lock file. If the file exists, then dont run.. the file can be empty, or it could contain the PID of the process.

Make sure if have a "die" handler that will remove the lock file if your script dies unexpectedly.

[jasonk]

My initial reaction is "why is this a CGI?", that seems like a solution looking for a problem.

That aside, what I would do is have the cgi script launch a process in the background, rather than having the cgi wait for it to finish. That way you could use lockfiles, and allow the subprocess to run even if the browser stops.

[extremely]

I know why it is a CGI. There was already a webserver running on the port, good programmers built the daemon to stay running, it handles the port it answers unambiguously, it provides a simple interface that can be accessed with just a couple lines of perl without understanding any of the high magic of networking, the webserver has authentication/authorization built in, and he already knew how to do it.

Unless you a are a masochist who gets off on network internals, why wouldn't you call a remote script using CGI? :)

--
$you = new YOU;
honk() if $you->love(perl)