Apart from the issue of creating user accounts on your server via a web form which I leave to your discretion now Abigail-II has warned you.
The three ideas I tried to describe in the CB are:
Write your own server process (another perlscript) that listens on a socket or a pipe and pass the data to the server process from your cgi script. No cron, actioned as soon as it is passed.
Instead of using a single large file to pass the data between the cgi script and the cron job, use small ones. One per account creation. That way the cgi creates them and the cron job process and deletes them. No locking or race conditions. Use the datetime to name the files to avoid conflict. Use a seperate directory to hold the files.
Use two data files and a sentinel file.
When the cron job starts, it looks for the sentinel file(an empty file whos job is to act as a signal) if it exists it deletes the file and waits a minute or two to make sure that the cgi script has finished writing to datafile1.
Then it opens, processes and empties datafile1 and dies.
If the sentinel file doesn't exist, it creates and waits a minute or two to make sure the cgi script has finished writing to datafile2. It then opens, processes and empties datafile2 and the dies.
When the cgi script is ready to add data to a datafile, it first checks for the existance of the sentinel file. If the sentinel exists, it writes to datafile1. If it doesn't, it writes to datafile2.
That way, the two processes can never be attempting to read/write to the same file at the same time.
The length of the delay that the processing script waits before open and processing a datafile will depend on how long the cgi script is likely to spend writing to it, but as you will want to respond to the person using the web page with a few seconds, 1 or 2 minutes should be ample.
In reply to Re: Script run as a Cron Job
by BrowserUk
in thread Script run as a Cron Job
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |