Home » Php » Php scripts (jobs) architecture. Is cron the ideal solution?

Php scripts (jobs) architecture. Is cron the ideal solution?

Posted by: admin July 12, 2020 Leave a comment


I am using crontab as the manager for administrative scripts and set up each job manually. Which seem to be very straight forward and perhaps ideal solution.

Problem that I realized is, that I don’t have any unified and automated control whether those scripts run fine all the time. Some of them are quite old… some are configured to send emails if problem occurs, others writes to custom error logs…

My plan is to unify all job scripts to strictly return correct status codes so I can just analyze crontab log (or custom log via “2>”) for issues. Perhaps even write some very simple job framework which will assert the unification and automate things for my needs…

Would you suggest some best practices? Or anything else? Or something to read about the topic before I start?


How to&Answers:

Cron tables are in deed the appropriate solution. Rewriting crontable in PHP would be both painful and uncertain on scheduling, unless you choose to use the fork functions, making it even more painful to write.

Launching the PHP script is pretty straight forward with wget, which gives you a bunch of logging utilities. Themselves being log rotatable for instance.

You should definitely share some job-tools.sh among your jobs scripts to always report their malfunctions, step by step.

Concerning the PHP script execution itself, you’d better rely on your standard PHP error log, which you probably already watch.