Posting in the Magento forums has been disabled pending the implementation of a new and improved forum solution which should better serve the community.

For new questions please post at magento.stackexchange.com, the community-run support site for the Magento community. We will be providing updates on the new forum solution soon. For questions or concerns please email community@magento.com.

Magento Forum

Page 9 of 10
Issues With Cron and Catalog price rules
 
chiefair
Mentor
 
Avatar
Total Posts:  1848
Joined:  2009-06-04
 

Yep, you’ve got it to a tee.

Cron.sh needs to be run periodically. The chain initiates and ends in the individual Magento module cron jobs being executed per their configs.

You can also manually trip a cron event by calling cron.php directly from your web browser. 

Using the shell script cron.sh takes care of an execution issue (can’t remember what exactly) that would otherwise crop up if you call cron.php directly from your crontab.

 
Magento Community Magento Community
Magento Community
Magento Community
 
youderian
Jr. Member
 
Total Posts:  20
Joined:  2009-07-15
 

Thanks for the reply!

Despite my best efforts, I wasn’t having success getting the logs cleared with Magento’s cron, so I went ahead and truncated all the “log” files in phpmyadmin.  The database dropped from 3GBs to around 200MB - much improved.  Unfortunately, when I try to export the smaller DB via ‘mysqldump’ at the command line, the resulting file produced is STILL the 3 GB size from before!  Exporting from phpmyadmin is better in that in produces a 200MB file, but I run into problems trying to re-import it on my local development machine. 

Is there something I need to do - similar to a rebuild, perhaps - after truncating multiple large tables to maintain the integrity of the mySQL database?  I somehow messed something up.....

 
Magento Community Magento Community
Magento Community
Magento Community
 
magework
Member
 
Avatar
Total Posts:  58
Joined:  2009-03-09
 

please check the URL below for your answer

Mage::Works

 
Magento Community Magento Community
Magento Community
Magento Community
 
youderian
Jr. Member
 
Total Posts:  20
Joined:  2009-07-15
 
gracevikram - 07 July 2011 09:18 AM

please check the URL below for your answer

Mage::Works

Thanks for the reply, but unless I’m missing something, this doesn’t solve the problem I have with the DB after truncating the logs.

 
Magento Community Magento Community
Magento Community
Magento Community
 
furnitureforyoultd
Enthusiast
 
Total Posts:  833
Joined:  2009-03-09
 

You could try gzipping the mysqldump file to if it’s too large, Our database was 250Mb+ in phpmyadmin, 180Mb from mysqldump and 19Mb after being gzipped.

mysqldump -u root -pPassword database | gzip -9 > database.sql.gz

 
Magento Community Magento Community
Magento Community
Magento Community
 
quicksand14
Sr. Member
 
Total Posts:  150
Joined:  2010-09-30
 

Is it possible that my cron job is working for SOME products? Could the promotions go away at random for other products? When I hit “APPLY PROMOTIONS” it fixes my issues… but before that its only like half the products that have issues. All at random times…

Since I’ve added the cron things are working much better but some of my products’ promotions are still going away.

PS I’m essentially using the promotions for the user groups to give users levels of discounts.

 
Magento Community Magento Community
Magento Community
Magento Community
 
youderian
Jr. Member
 
Total Posts:  20
Joined:  2009-07-15
 
gracevikram - 07 July 2011 09:18 AM

please check the URL below for your answer

Mage::Works

After more digging, I realize the problem is many of the sales_flat_quote_* tables in the database, which are taking up more than 2 GB!

I looked at this link (thank you, BTW) which discusses changing the cron.php file, but it doesn’t really say what it will do.  Will this edit remove the large sales_flat_quote tables?  If not, is there a good solution to get these smaller?  I can’t imagine what is in there and a quick search on the forums didn’t reveal much.....

 
Magento Community Magento Community
Magento Community
Magento Community
 
chiefair
Mentor
 
Avatar
Total Posts:  1848
Joined:  2009-06-04
 
youderian - 07 July 2011 09:02 AM

Thanks for the reply!

Despite my best efforts, I wasn’t having success getting the logs cleared with Magento’s cron, so I went ahead and truncated all the “log” files in phpmyadmin.  The database dropped from 3GBs to around 200MB - much improved.  Unfortunately, when I try to export the smaller DB via ‘mysqldump’ at the command line, the resulting file produced is STILL the 3 GB size from before!  Exporting from phpmyadmin is better in that in produces a 200MB file, but I run into problems trying to re-import it on my local development machine. 

Is there something I need to do - similar to a rebuild, perhaps - after truncating multiple large tables to maintain the integrity of the mySQL database?  I somehow messed something up.....

Welll…

Sounds like the first problem is to get all the log tables shrunk down in size. Truncating them and doing a MySQLDump shouldn’t still be producing huge files. The dump is a bazillion mysql commands that recreate the tables, not an actual binary backup of the file, so eliminated data should equal smaller mysqldump output. Not sure what’s happening here???

If you’re running Magento 1.4.x.x, it includes scripts to do log table maintenance. You can fire it off with the system crontab for routine maintenance.

php -f ./shell/log.php help gives you a listing of the various options

php -f ./shell/log.php status gives you a listing of the log tables, how many rows and the size of storage space contained in the tables and indexes.

php -f ./shell/log.php clean --days 15 will clear all but the last 15 days of log contents (minimum 1 day)

php -f ./shell/log.php clean clears everthing per your settings in system setups under log maintenance

If you are running an earlier version that doesn’t have the shell/log.php script, Crucial Webhost created this script that will truncate the tables, including the dataflow_batch_x files which have been known to grow endlessly as well. Once again, this can be run with the system crontab to keep things from bloating.

Since most of this started with a couple truncate operations, in phpMyAdmin, if you click on the table in consideration and go to the operations tab, you have the following options:

Table maintenance

* Check table
* Defragment table
* Optimize table
* Flush the table ("FLUSH")

CHECK TABLE checks a table or tables for errors. CHECK TABLE works for MyISAM, InnoDB, and (as of MySQL 5.0.16) ARCHIVE tables. For MyISAM tables, the key statistics are updated as well.

OPTIMIZE TABLE should be used if you have deleted a large part of a table or if you have made many changes to a table with variable-length rows (tables that have VARCHAR, VARBINARY, BLOB, or TEXT columns). Deleted rows are maintained in a linked list and subsequent INSERT operations reuse old row positions. You can use OPTIMIZE TABLE to reclaim the unused space and to defragment the data file. After extensive changes to a table, this statement may also improve performance of statements that use the table, sometimes significantly.

OPTIMIZE TABLE works only for MyISAM, InnoDB, and (as of MySQL 5.0.16) ARCHIVE tables. It does not work for tables created using any other storage engine.

As a for instance, we can assume the report_event table is getting a little crufty. We can check it for problems, if it passes, then optimize it with the following commands:

CHECK TABLE ‘report_event’;
OPTIMIZE TABLE ‘report_event’;

YMMV and a good system backup before attempting…

 
Magento Community Magento Community
Magento Community
Magento Community
 
youderian
Jr. Member
 
Total Posts:  20
Joined:  2009-07-15
 

Thank you for such a detailed and comprehensive reply!  This was exactly what I needed.  Along with these tips, and a few other things, I was able to shrink the DB to 107 MB (from 3.5GB) and get a clean export.

Here are a few tips I discovered that, as someone new to this, I hope will help others:

1) Using the mysql and mysqldump command line tools are MUCH more reliable than importing & exporting from phpmyadmin with large DBs.  Taking a few minutes to get familiar with them will save you a lot of headache down the road.

2) The “tail” command is very useful in seeing if a DB export was successful.  Some of my early problems stemmed from the fact that the phpmyadmin tool had an error 1/2 way through export, but did\’t report it, and I was trying to import a .sql dump that was corrupt.  To ensure you have a complete, finished .sql dump file you can run from a command line:

tail -n 50 databasename.sql

...which will output the last 50 lines of the DB to your screen.  If the dump completed successfully, you\’ll see something like:

Dump completed on 2011-07-08 14:46:41

This is much more convenient than trying to open up a 100MB+ DB file with a text editor, which can often be really cumbersome.

3) The sales_flat_quote_* series of tables also gets enormous over time, and as it is listed on the 2nd page of phpmyadmin for a standard Magento install, can be easier to overlook than the log_* series of file.  There are numerous other posts that deal with this.

 
Magento Community Magento Community
Magento Community
Magento Community
 
chiefair
Mentor
 
Avatar
Total Posts:  1848
Joined:  2009-06-04
 

Glad to be of help!

Thanks for the reminder on “tail” as incomplete database dumps were some of my earliest Magento Fail hall of fame entries.

Our web developer put us on a really inadequate shared test server that had issues with tiny default MySQL log files (transactional integrity system) and 128MB memory_limit for php. Despite being told over and again, they never quite got the concept of the sheer amount of data our company works with. I begged and plead to get the memory_limit increased (never happened) and after several bad dumps in phpMyAdmin, got them to make a tweak or two, which a month later, came back because of the low memory_limit.

As you said, there’s a really good reason to use the command line. It’s quicker, doesn’t waste resources making things pretty and therefore more reliable. In the end, the Magento backups were the only thing working, so I would pull them from the test server and restore them internally on our dev server where I had allocated the resources really needed for Magento to run in order to do the things that would fail because Magento would throw an “out of memory” error.

Cron-able Magento DB backup script (uses Magento’s Backup)

 
Magento Community Magento Community
Magento Community
Magento Community
 
chiefair
Mentor
 
Avatar
Total Posts:  1848
Joined:  2009-06-04
 

Since someone asked somewhere along the line, here’s an update to the Cron Job Monitor Script that A) tells you the UTC time, b) the server time and offset and c) your store time (single storefront). It’s being run in a folder under the Magento root folder.

<?php
//Magento Cron Job Monitor. GNU/GPL
//oliver.higgins@gmail.com
//provided without warranty or support
//
//modifications by chiefair to retrieve Magento connection and database
//info, display time, connection info and all job execution states
//================================================================

/** Get current date, time, UTC and offset **/
$date   date("Y-m-d");
$time   date("H:i:s T");
$offset date("P");
$utc    gmdate("H:i:s");

/** Mage locations **/
$mageconf '../app/etc/local.xml';  // Mage local.xml config
$mageapp  '../app/Mage.php';       // Mage app location

/*******************
 * Let George do it
 * Get connection information from Magento's local.xml file
 *******************/

if (file_exists($mageconf)) {

$xml 
simplexml_load_file('../app/etc/local.xml'NULLLIBXML_NOCDATA);

$db['host'$xml->global->resources->default_setup->connection->host;
$db['name'$xml->global->resources->default_setup->connection->dbname;
$db['user'$xml->global->resources->default_setup->connection->username;
$db['pass'$xml->global->resources->default_setup->connection->password;
$db['pref'$xml->global->resources->db->table_prefix;

$tblname$db['pref'"cron_schedule";



else {
    
exit('Failed to open ../app/etc/local.xml');
}

/* Initialize profile to be run as Magento Admin and log start of export */

require_once $mageapp;
umask(0);
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

$storetimestamp Mage::getModel('core/date')->timestamp(time());

$storetime date("H:i:s",$storetimestamp);

/************************
 * Start HTML output
 ************************/

echo '<html><head><title>Magento Cron Schedule on ' $date ' ' $time '</title>
<meta http-equiv="refresh" content="60">
<style type="text/css">html {width: 100%; font-family:  Arial,Helvetica, sans-serif;}
body {line-height:1.0em; font-size: 100%;}
table {border-spacing: 1px; width: 100%;}
th.stattitle {text-align: left; font-size: 100%; font-weight: bold; color: white; background-color: #101010;}
th {text-align: center; font-size: 80%; font-weight: bold; padding: 5px; border-bottom: 1px solid black; border-left: 1px solid black; }
td {text-align: left; font-size: 80%; padding: 4px; border-bottom: 1px solid black; border-left: 1px solid black;}
</style>
</head><body>'
;

/** Output title, connection info and cron job monitor runtime **/

echo "<h2>Magento Cron Schedule Report</h2><h3>Connection: ".$db['user']."@".$db['host']."&nbsp;&nbsp;&ndash;&nbsp;&nbsp;Database: " $db['name'"&nbsp;&nbsp;&ndash;&nbsp;&nbsp;Table: " $tblname "</h3>";
echo 
"<h4>Runtime: " $date "&nbsp;&nbsp;&nbsp;Server: " .$time "&nbsp;&nbsp;&nbsp;Store: " .$storetime "&nbsp;&nbsp;&nbsp;Zulu: " $utc " UTC</h4>";
echo 
"<h4>Note: All logged times are UTC, your server timezone offset is " $offset " hours from UTC</h4>";

/** Connect to database **/

$conn mysql_connect($db['host'],$db['user'],$db['pass']);
@
mysql_select_db($db['name']) or die(mysql_error());

//================================================================
//Pending jobs

$query='SELECT * FROM ' $tblname ' WHERE status ="pending" ORDER BY scheduled_at DESC' ;
$result=mysql_query($query);
$num=mysql_numrows($result);
echo 
'<table><tbody><tr><th class="stattitle" colspan="5">Jobs Pending: ' $num '</th></tr>';
echo 
"<tr><th>ID</th><th>Job Code</th><th>Status</th><th>Created At</th><th>Scheduled At</th>";
$i=0;
while (
$i $num{

$schedule_id
=mysql_result ($result,$i,"schedule_id");                                      
$job_code=  mysql_result($result,$i,"job_code");
$status=mysql_result ($result,$i,"status");
$created_at=mysql_result ($result,$i,"created_at");
$scheduled_at=mysql_result ($result,$i,"scheduled_at");
$executed_at=mysql_result ($result,$i,"executed_at");
$finished_at=mysql_result ($result,$i,"finished_at");

//output html
echo "<tr>";
echo 
"<td>".$schedule_id."</td>";
echo 
'<td>'.$job_code."</td>"
echo 
'<td style="color: red;">'.$status."</td>"
echo 
"<td>".$created_at."</td>"
echo 
"<td>".$scheduled_at."</td>"
echo 
"</tr>";                 
$i++;
}
echo "</tbody></table><hr>";

//================================================================
//Running jobs

$query='SELECT * FROM ' $tblname ' WHERE status ="running" ORDER BY executed_at DESC' ;
$result=mysql_query($query);
$num=mysql_numrows($result);
echo 
'<table><tbody><th class="stattitle" colspan="7">Jobs Running: ' $num '</th></tr>';
echo 
"<tr><th>ID</th><th>Job Code</th><th>Status</th><th>Created At</th><th>Scheduled At</th>";
echo 
"<th>Executed At</th><th>Finished At</th></tr>";
$i=0;
while (
$i $num{

$schedule_id
=mysql_result ($result,$i,"schedule_id");                                      
$job_code=  mysql_result($result,$i,"job_code");
$status=mysql_result ($result,$i,"status");
$created_at=mysql_result ($result,$i,"created_at");
$scheduled_at=mysql_result ($result,$i,"scheduled_at");
$executed_at=mysql_result ($result,$i,"executed_at");
$finished_at=mysql_result ($result,$i,"finished_at");

//output html
echo "<tr>";
echo 
"<td>".$schedule_id."</td>";
echo 
"<td>".$job_code."</td>"
echo 
"<td>".$status."</td>"
echo 
"<td>".$created_at."</td>"
echo 
"<td>".$scheduled_at."</td>"
echo 
"<td>".$executed_at."</td>"
echo 
"<td>".$finished_at."</td>"
echo 
"</tr>";                 
$i++;
}
echo "</tbody>";

//================================================================
//Succsessful jobs

$query='SELECT * FROM ' $tblname ' WHERE status ="success" ORDER BY executed_at DESC' ;
$result=mysql_query($query);
$num=mysql_numrows($result);
echo 
'<tbody><tr><th class="stattitle" colspan="7">Jobs Successful: ' $num '</th></tr>';
echo 
"<tr><th>ID</th><th>Job Code</th><th>Status</th><th>Created At</th><th>Scheduled At</th>";
echo 
"<th>Executed At</th><th>Finished At</th></tr>";
$i=0;
while (
$i $num{

$schedule_id
=mysql_result ($result,$i,"schedule_id");                                      
$job_code=  mysql_result($result,$i,"job_code");
$status=mysql_result ($result,$i,"status");
$created_at=mysql_result ($result,$i,"created_at");
$scheduled_at=mysql_result ($result,$i,"scheduled_at");
$executed_at=mysql_result ($result,$i,"executed_at");
$finished_at=mysql_result ($result,$i,"finished_at");

//output html
echo "<tr>";
echo 
"<td>".$schedule_id."</td>";
echo 
"<td>".$job_code."</td>"
echo 
"<td>".$status."</td>"
echo 
"<td>".$created_at."</td>"
echo 
"<td>".$scheduled_at."</td>"
echo 
"<td>".$executed_at."</td>"
echo 
"<td>".$finished_at."</td>"
echo 
"</tr>";                 
$i++;
}
echo "</tbody>";

//================================================================
//Missed jobs

$query='SELECT * FROM ' $tblname ' WHERE status ="missed" ORDER BY executed_at DESC' ;
$result=mysql_query($query);
$num=mysql_numrows($result);
echo 
'<tbody><tr><th class="stattitle" colspan="7">Jobs Missed: ' $num '</th></tr>';
echo 
"<tr><th>ID</th><th>Job Code</th><th>Status</th><th>Created At</th><th>Scheduled At</th>";
echo 
"<th>Executed At</th><th>Finished At</th></tr>";
$i=0;
while (
$i $num{

$schedule_id
=mysql_result ($result,$i,"schedule_id");                                      
$job_code=  mysql_result($result,$i,"job_code");
$status=mysql_result ($result,$i,"status");
$created_at=mysql_result ($result,$i,"created_at");
$scheduled_at=mysql_result ($result,$i,"scheduled_at");
$executed_at=mysql_result ($result,$i,"executed_at");
$finished_at=mysql_result ($result,$i,"finished_at");

//output html
echo "<tr>";
echo 
"<td>".$schedule_id."</td>";
echo 
"<td>".$job_code."</td>"
echo 
"<td>".$status."</td>"
echo 
"<td>".$created_at."</td>"
echo 
"<td>".$scheduled_at."</td>"
echo 
"<td>".$executed_at."</td>"
echo 
"<td>".$finished_at."</td>"
echo 
"</tr>";                 
$i++;
}
echo "</tbody>";

//================================================================
//Failed jobs

$query='SELECT * FROM ' $tblname ' WHERE status ="error" ORDER BY executed_at DESC' ;
$result=mysql_query($query);
$num=mysql_numrows($result);
echo 
'<tbody><tr><th class="stattitle" colspan="7">Jobs Failed: ' $num '</th></tr>';
echo 
"<tr><th>ID</th><th>Job Code</th><th>Status</th><th>Created At</th><th>Scheduled At</th>";
echo 
"<th>Executed At</th><th>Finished At</th></tr>";
$i=0;
while (
$i $num{

$schedule_id
=mysql_result ($result,$i,"schedule_id");                                      
$job_code=  mysql_result($result,$i,"job_code");
$status=mysql_result ($result,$i,"status");
$created_at=mysql_result ($result,$i,"created_at");
$scheduled_at=mysql_result ($result,$i,"scheduled_at");
$executed_at=mysql_result ($result,$i,"executed_at");
$finished_at=mysql_result ($result,$i,"finished_at");

//output html
echo "<tr>";
echo 
"<td>".$schedule_id."</td>";
echo 
"<td>".$job_code."</td>"
echo 
"<td>".$status."</td>"
echo 
"<td>".$created_at."</td>"
echo 
"<td>".$scheduled_at."</td>"
echo 
"<td>".$executed_at."</td>"
echo 
"<td>".$finished_at."</td>"
echo 
"</tr>";                 
$i++;
}
echo "</tbody></table></body></html>";

//================================================================
// End of report

mysql_close($conn);
?>

Somewhere along the line when I get some time, I’ll also do the PDO rewrite as suggested. As you can see, it can get a little confusing when you can have three different time zones to chase down as our store does. Execution times are logged in UTC,

 
Magento Community Magento Community
Magento Community
Magento Community
 
nangko
Jr. Member
 
Total Posts:  6
Joined:  2010-01-25
 

Can I change the cron_expr for “catalogrule_apply_all” from: 0 1 * * * to: 0 0 * * * ??
Or is there a good reason why it’s set too 1 o clock

I want to make this change because it seems like my product rules turn inactive at 00:00 and are activated at 01:00.
(can some one confirm this for me?)

And I want my price rules always be active.

 
Magento Community Magento Community
Magento Community
Magento Community
 
minolone
Jr. Member
 
Total Posts:  1
Joined:  2010-09-20
 

Hi for all.
I have a problem with corn, catalogrule_apply_all
gets error

exception 'PDOException' with message 'SQLSTATE[21S01]: Insert value list does not match column list: 1136 Column count doesn't match value count at row 4' in /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Statement/Pdo.php:228
Stack trace:
#0 /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Statement/Pdo.php(228): PDOStatement->execute(Array)
#1 /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array)
#2 /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)
#3 /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('
replace into ca...', Array)
#4 /var/www/vhosts/strona-www/httpdocs/lib/Varien/Db/Adapter/Pdo/Mysql.php(337): Zend_Db_Adapter_Pdo_Abstract->query('
replace into ca...', Array)
#5 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/CatalogRule/Model/Mysql4/Rule.php(600): Varien_Db_Adapter_Pdo_Mysql->query('
replace into ca...')
#6 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/CatalogRule/Model/Mysql4/Rule.php(506): Mage_CatalogRule_Model_Mysql4_Rule->_saveRuleProductPrices(Array)
#7 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/CatalogRule/Model/Observer.php(195): Mage_CatalogRule_Model_Mysql4_Rule->applyAllRulesForDateRange()
#8 [internal function]: Mage_CatalogRule_Model_Observer->dailyCatalogUpdate(Object(Noovias_Cron_Model_Schedule))
#9 /var/www/vhosts/strona-www/httpdocs/app/code/local/Aoe/Scheduler/Model/Observer.php(73): call_user_func_array(Array, Array)
#10 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/Core/Model/App.php(1272): Aoe_Scheduler_Model_Observer->dispatch(Object(Varien_Event_Observer))
#11 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/Core/Model/App.php(1253): Mage_Core_Model_App->_callObserverMethod(Object(Aoe_Scheduler_Model_Observer), '
dispatch', Object(Varien_Event_Observer))
#12 /var/www/vhosts/strona-www/httpdocs/app/Mage.php(416): Mage_Core_Model_App->dispatchEvent('
default', Array)
#13 /var/www/vhosts/strona-www/httpdocs/cron.php(44): Mage::dispatchEvent('
default')
#14 {main}

Next exception '
Zend_Db_Statement_Exception' with message 'SQLSTATE[21S01]Insert value list does not match column list: 1136 Column count doesn't match value count at row 4' in /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Statement/Pdo.php:234
Stack trace
:
#0 /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array)
#1 /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)
#2 /var/www/vhosts/strona-www/httpdocs/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('replace into ca...', Array)
#3 /var/www/vhosts/strona-www/httpdocs/lib/Varien/Db/Adapter/Pdo/Mysql.php(337): Zend_Db_Adapter_Pdo_Abstract->query('replace into ca...', Array)
#4 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/CatalogRule/Model/Mysql4/Rule.php(600): Varien_Db_Adapter_Pdo_Mysql->query('replace into ca...')
#5 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/CatalogRule/Model/Mysql4/Rule.php(506): Mage_CatalogRule_Model_Mysql4_Rule->_saveRuleProductPrices(Array)
#6 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/CatalogRule/Model/Observer.php(195): Mage_CatalogRule_Model_Mysql4_Rule->applyAllRulesForDateRange()
#7 [internal function]: Mage_CatalogRule_Model_Observer->dailyCatalogUpdate(Object(Noovias_Cron_Model_Schedule))
#8 /var/www/vhosts/strona-www/httpdocs/app/code/local/Aoe/Scheduler/Model/Observer.php(73): call_user_func_array(Array, Array)
#9 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/Core/Model/App.php(1272): Aoe_Scheduler_Model_Observer->dispatch(Object(Varien_Event_Observer))
#10 /var/www/vhosts/strona-www/httpdocs/app/code/core/Mage/Core/Model/App.php(1253): Mage_Core_Model_App->_callObserverMethod(Object(Aoe_Scheduler_Model_Observer), 'dispatch', Object(Varien_Event_Observer))
#11 /var/www/vhosts/strona-www/httpdocs/app/Mage.php(416): Mage_Core_Model_App->dispatchEvent('default', Array)
#12 /var/www/vhosts/strona-www/httpdocs/cron.php(44): Mage::dispatchEvent('default')
#13 {main}
 
Magento Community Magento Community
Magento Community
Magento Community
 
Brake6
Sr. Member
 
Total Posts:  87
Joined:  2008-09-23
 

Thanks for all the valuable tips here – it really helped me getting closer to a solution. But, I have still one problem. First, I’m running Magento 1.4.1.1 on a Mac OS X Server (10.6).

Here are my issue:
1. When running this command directly in the Terminal I get the “confirmation” email sent (looks like it works as supposed to):

sudo php ./cron.php

2. If I have this entry in root’s crontab no email is sent:

php /Library/WebServer/Documents/snus2/cron.php

It looks like cron.php starts to run because the CPU load (%) rising up to 100% (higher and higher for each time cron trigger the cron.php page). And the PHP process is then in 90-95% area.

Anyone knows what the problem is and how to solve it?

Regards, Magnus

 
Magento Community Magento Community
Magento Community
Magento Community
 
jarhody
Jr. Member
 
Total Posts:  20
Joined:  2009-03-10
 

My Cron email says this. Any ideas why?

PHP Notice:  Undefined index:  SCRIPT_NAME in /path/to/cron.php on line 36
PHP Notice:  Undefined index:  SCRIPT_FILENAME in /path/to/cron.php on line 37
X-Powered-By: PHP/5.2.5
Content-type: text/html

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top
Page 9 of 10