Cron Setup Schedules in Magento 1.7 and 1.6

magento-1.6magento-1.7

I have the following questions.

1) Magento provides cron.php, shell/log.php & shell/indexer.php

And I have set them up as follows.These are just examples set up. These can be modified for the proper output/functioning/scheduling.

*/60 * * * * sudo /opt/lampp/bin/php /opt/lampp/htdocs/magento/shell/log.php clean >> /opt/lampp/htdocs/magento/var/log/cronlog.txt

*/60 * * * * sudo /opt/lampp/bin/php /opt/lampp/htdocs/magento/shell/indexer.php reindexall >> /opt/lampp/htdocs/magento/var/log/cronindexer.txt

*/60 * * * * sudo /opt/lampp/bin/php /opt/lampp/htdocs/magento/cron.php clean >> /opt/lampp/htdocs/magento/var/log/croncron.txt

Is this the correct set up, or only setting cron.php does the all things viz removing logs, performing indexing, cleaning up the cache, etc.

2) Magento provides the cron settings in the back end also(system -> config -> system -> Cron (Scheduled Tasks) – all the times are in minutes) where we enter frequency for the tasks. By setting this option up again we need to go to option 1 described above. So what is the purpose of giving frequency/times in both cases(crontab & backend settings) and what times/frequencies will be taken into account.

I clearly do not understand this. Can anyone throw some light?

Best Answer

Output

You're redirecting output to log files - that's fine - but those logs may become bloated over time or full of warnings and errors that you have no intention of looking at. At minimum configure these files with a standard .log extension in /var/log/ and configure a logrotate job to compress them after some time.

However, I don't redirect output at all. The reason is that any output during a cron job will be logged to the /var/log/cron file. In addition, crontab can be configured, per user, to email the output. There are some Magento modules that return their own model during the cron process and thus Magento logs the name of the model - storing it in the cron log database table. This is undesirable for me, and useless output.

You can get a visual overview of logs run using a fantastic plugin from the folks at Aoe and @fbrnc - Aoe_Scheduler. Its location is here on Github: https://github.com/fbrnc/Aoe_Scheduler

Sudoer

There should be no reason to execute PHP as sudoer, as the PHP scripts in question will only reach out and touch the DB. They should only need to have read access.

indexer.php

Reindexing every hour is also unnecessary. I would schedule the indexer to run overnight, possibly, or during your off-peak hours.

cron.php

Cleaning the cron logs is something that I would do every 30-60 days, not hourly. You will still need to configure a job that doesn't explicitly clean the cron, but rather calls the cron.php on its own. This should be set up to run every 5 to 10 minutes. Magento schedules jobs 15 minutes in advance, but only runs them as often as your cron is running. Personally, I configure cron.php to run every 5 minutes.

There is some debate over whether to run cron as a PHP process or a shell script. From my understanding if you run it as PHP, it will not block the next scheduler request from running if the previous instance is still running from the last cron execution, which may be desirable. If you use the bash script, it will block. How you want this to operate is up to you, if you prefer not to have jobs run concurrently.

log.php

This is a good one to run nightly before or after your indexer completes. If you have a large db, I recommend spacing this out by 2-3 hours, because your Indexes may take several hours to complete, especially if you have flat catalog enabled.

If you've never run this, or run it quite infrequently, you may want to run log.php clean on its own the first time with no other scheduled jobs, and you may want to enable the maintenance message on your store. The reason being is that in my experience any locking to the log tables cause significant visible issues to customers in your store.

Because the log tables are stored in the DB, writes get queued up behind your deletes, and, well, it can be apocalyptic (I had a client with 100MM records in their visitor log table - we just had to archive offline, truncate and start over; no delete job would complete during a maintenance window).

I hope this helps. Best of luck.

Related Topic