"cronjob-like" system

Hi philones85,

I thought, that I just run one php-file per lynx -dump on a machine and thus file does the planned processes and saves the concurrent log.

Do you have additional tipps?

Kind regards
Henning

You can do it that way, but that requires that you run lynx every time you want the file to execute.  If you use the local cron, it will do it automatically.  If you're managing many machines, and change the frequency that you want to execute the program often, using one system's cron to run lynx and execute the code on all the other machines is an option...

My target is, that one script processes all required functions when it is needed. In example:

every hour: checking for new bills
every day: booking of money transfers
every day: updating old/outdated contracts
every 2 hours: Checking integrity

Something like that. And, because of its complexity and volume of jobs, I'd prefer an system with one php-file... In the best case with mysql database as backend.

Kind regards
Henning

Then a PHP daemon is really your only choice. The script must run all the time, because there is no 'boot-strap' option that will cause it to wake up at the desired times (outside of an external helper like cron).

Your daemon will simply check if any existing jobs need to be done, and execute them. Then it will sleep for the amount of time you specific (using the sleep() function), and wake up again to check for jobs.

I use a program like this to check for incoming data feeds for a product comparison site, and it works quite well.

furthermore, you could set your php script up to allow you to run any function you wanted manually through your wget call as well if you have a need to run something immediately

<?php

if ($argv[1] == 'new_bills' || $_GET['action'] = 'new_bills')
{
  // check for new bills
}
if ($argv[1] == 'money_transfers' || $_GET['action'] == 'money_transfers')
{
  // booking of money transfers
}
if ($argv[1] == 'update_contracts' || $_GET['action'] == 'update_contracts')
{
  // update old/outdated contracts
}
if ($argv[1] == 'check_integrity' || $_GET['action'] == 'check_integrity')
{
  // check integrity
}
?>

then you could call it with
wget www.domain.com/path/to/file.php?action=check_integrity

Whats about a table, which looks like a cron table, with hours, minutes and so on? Does it also work?

Kind regards
Henning

Yes, that will work. Your script checks the table, selected jobs with times matching or near the current time, and execute them.

Do you have a tut for something like that?

Kind regards
Henning

do you have a reason why you don't want to use cron?  are you planning on creating a daemon?

No, I do not know of any tutorial that would cover the specific type of application you are requesting. However, you can break it down into these steps:

1. Create the database that holds the job information, including execution time.
2. Create the script to access the database, and compare the current time to the scheduled job time.
3. Create the job execution portion of the script.
4. Add the process control/daemon portion to the script so that it will remain running.

The reason is, that it is a CRM and billing system, coded by myself. My target is, that the system is dynamically and can be edited. Also the script execution for updating the services. So I thought, to create a php-script which will be executed every minute and checks for the tasks to do.

Kind regards
Henning

You can certainly use cron for the "executed every minute" part, if you desire. Then the script itself will only have to check the available jobs, and execute them.

Hi glcummins,

thats my target ;o)
But I dunno how to create such a system for the jobs, that has to be executed? Only one idea:
Last run, grace period, name, description, command.

Is that a start?

Kind regards
Henning

Yes, that sounds right. If grace period is larger than (current time - last run), then run the job, and update last run.

You will also want to build a good logging system, so that you can see what happened if something breaks. Since this will not be a screen-output program, you will need it to log extensively to a file or database.

Finally, you will want to make sure that the program does not step on it's own toes. It needs to be able to check if another instance of the program is already running (from the previous minute's execution), and exit gracefully as needed.

I thought for the following table structure:

jobid | jobname | jobran | jobperiod (in seconds) | jobrunning

Is that ok?

The only thing I would comment on is 'jobrunning'. The current script will know if there is a job running, so the only benefit that field will have is to another instance of the script. I would recommend that you put a system in place that prevents multiple instances of the script from running, so that you avoid problems with hung jobs. If your script is running and hanging for some reason, you don't want 57 instances of the script running in memory before you find it about an hour later.

You can create a lock file with your script that will notify future instances that the script is still running. If the lock file exists, the new instance simply exists, and tries again on minute later.

But, there could be many instances running because of many jobs. One job should run only a one instance.

Kind regards
Henning

Hm... Okay. In that case, your table structure suggestion was correct. You should have something in place, however, to recognize hung processes and deal with them as necessary.

And how? :S

Well, the 'how' is up to you. There are a number of possibilities:

1. Specify a 'reasonable' job time. Add a 'startTime' field to the table. Each time your script runs, look for jobs that have been running for longer than that time period and kill as necessary.

2. Have your script check the output of 'top' for processes matching the name of your script. Check the TIME field, and kill any that have been running longer than they should.

3. Set a maximum number of concurrent instances that can run. Increment a field in the database each time a script starts, and decrement it when the script ends. If a script checks this field and finds that too many instances are running, it can exit, exit and notify (perhaps by email), or kill the oldest script.