How do I restore this script after a hardware failure?

Question

Hi there,

I know this is a bit generic, but I'm sure you'll understand my explanation. Here is the situation:

---

The following code is executed every 10 minutes. Variable "var_x" is always read/written to an external text file when its refereed to.

if ( var_x != 1 )
{
   var_x = 1;
   //
   // here is where the main body of the script is.
   // it can take hours to completely execute.
   //
   var_x = 0;
}
else
{
   // exit script as it's already running.
}

---

The problem is: if I simulate a hardware failure (do a hard reset when the script is executing) then the main script logic will never execute again because "var_x" will always be "1". (I already have logic to work out the restore point).

Thanks.

Answer 1

It sounds like you're doing some kind of manual semaphore for process management.

Rather than writing to a file, perhaps you should use an environment variable instead. That way, in the event of failure, your script will not have a closed semaphore when you restore.

Answer 2

Don't you think this would be better solved using file locks? (When the reset occurs file locks are reset as well)

http://php.net/flock

Answer 3

You should lock and unlock files with flock:

$fp = fopen($your_file);
if (flock($fp, LOCK_EX)) { )
{
   //
   // here is where the main body of the script is.
   // it can take hours to completely execute.
   //
    flock($fp, LOCK_UN);
}
else
{
   // exit script as it's already running.
}

Edit:

As flock seems not to work correctly on Windows machines, you have to resort to other solutions. From the top of my head an idea for a possible solution:

Instead of writing 1 to var_x, write the process ID retrieved via getmypid. When a new instance of the script reads the file, it should then lookup for a running process with this ID, and if the process is a PHP script. Of course, this can still go wrong, as there is the possibility of another PHP script obtaining the same PID after a hardware failure, so the solution is far from optimal.