Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.6
-
Component/s: Administration
-
Labels:None
-
Environment:All
-
Database:Any
-
Affected Branches:MOODLE_16_STABLE
-
Fixed Branches:MOODLE_17_STABLE, MOODLE_18_STABLE
Description
I'm trying to get the stats to work on a 1.6.1+ install (also 1.6.2). It seems to run away and never return. I set the stats settings so that it only went back a week, but it still never seems to end.
Info:
1. Site has about 125 courses.
2. 800 users.
3. Stats settings are set to look one week back and run no longer than an hour.
4. After running for more than an hour, the 'stats_monthly' table has 2,344,571 records in it (it started empty), 'stats_daily', 'stats_user_daily' and 'stats_user_monthly' are empty, 'stats_user_weekly' has 195 records, and 'stats_weekly' has 136 records.
5. If I access the stats functions, I get the message "There is no available data to display, sorry".
After running some tests we discovered that the run ends up in an infinite loop in the 'stats_cron_monthly' function. In particular, the iterator of the loop, function stats_get_next_monthend, never increments the value. It stays the same.
The function stats_get_next_monthend is doing some funky stuff with timestamps. The code reads:
function stats_get_next_monthend($lastmonth) {
return stats_getmidnight(strtotime(date('1-M-Y',$lastmonth).' +1 month'));
}
Issue Links
| This issue is duplicated by: | ||||
| MDL-6310 | stats_cron_monthly infinite loop for negative timezones |
|
|
|
| This issue has a non-specific relationship to: | ||||
| MDL-7272 | Remove custom timezone handling when PHP5 is required |
|
|
|
| This issue has been marked as being related by: | ||||
| MDL-7385 | "Statistics is currently in catchup mode. So far 0 day(s) have been processed and 365 are pending "doesn't catch up |
|
|
|
Activity
Hola! Just been though the code with Penny and I think we have a problem with the TZ handling that may or may not be the cause ofthe infinite loop. To actually debug the infinite loop, we'd like to see an installation that shows it – we haven't had any luck reproducing this :-/
The problem we are seeing is that those calles to date() and strtotime() are bogus, We cannot really use date() and we can only use strtotime() in very specific cases in Moodle because we are not using PHP's standard date/time functions, and instead we have our home-brewed TZ stuff that doesn't quite cover what strtotime() does. date() isn't such a problem, but strtotime() is very rich in what it does...
Targetting 1.8 the fix would be to go back to PHP's native date/time functions as described in MDL-7272 (linked now). For 1.7 we can
- Set $ENV[TZ] to get strtotime() to use our timezone
- Rewrite the logic to find a way to suss out the 1st of each month without strtotime() – or at least without forcing it to guess a tz
- Or we could write our own strtotime() implementation.
Again – I don't know if this TZ problem is the cause of the bug.
Targetting 1.8 the fix would be to go back to PHP's native date/time functions as described in MDL-7272 (linked now). For 1.7 we can
- Set $ENV[TZ] to get strtotime() to use our timezone
- Rewrite the logic to find a way to suss out the 1st of each month without strtotime() – or at least without forcing it to guess a tz
- Or we could write our own strtotime() implementation.
Repost (as Jira doesn't seem to email out if you post it as a comment to a link action):
Hola! Just been though the code with Penny and I think we have a problem with the TZ handling that may or may not be the cause ofthe infinite loop. To actually debug the infinite loop, we'd like to see an installation that shows it – we haven't had any luck reproducing this :-/
The problem we are seeing is that those calles to date() and strtotime() are bogus, We cannot really use date() and we can only use strtotime() in very specific cases in Moodle because we are not using PHP's standard date/time functions, and instead we have our home-brewed TZ stuff that doesn't quite cover what strtotime() does. date() isn't such a problem, but strtotime() is very rich in what it does...
Targetting 1.8 the fix would be to go back to PHP's native date/time functions as described in MDL-7272 (linked now). For 1.7 we can
- Set $ENV[TZ] to get strtotime() to use our timezone
- Rewrite the logic to find a way to suss out the 1st of each month without strtotime() – or at least without forcing it to guess a tz
- Or we could write our own strtotime() implementation.
Again – I don't know if this TZ problem is the cause of the bug.
Targetting 1.8 the fix would be to go back to PHP's native date/time functions as described in MDL-7272 (linked now). For 1.7 we can
- Set $ENV[TZ] to get strtotime() to use our timezone
- Rewrite the logic to find a way to suss out the 1st of each month without strtotime() – or at least without forcing it to guess a tz
- Or we could write our own strtotime() implementation.
More information/comments from a partners post:
At the risk of saying something dumb, I will put in my 2 cents worth smile. I think there are some other issues. May just be my lack of understanding of the code but here are two issues I can't account for
1) In daily stats nextmidnight is assigned to
$nextmidnight = stats_get_next_dayend($timestart);
I believe stats_get_next_dayend adds one day to the $timestart and then makes a call to some time zone handling code. However $timestart is prevously assigned a value that is normalized to the time zone. If the intension to actually increment the value by one day that adjusting for time zone a second time would produce an incorrect result. This value would be off variably depending on any differences between the time zone of the server and the defined time zone in Moodle. In our case on my test server, the above line actually results in $nextmidnight being assigned the same value as $timestart, which caused the daily processing loop to never start since if fails the $timestart < $nextmidnight clause.
Honestly I haven't quite digested the time zone adjustment code, so maybe I am off base, but it it works as it seems it should then it must be getting called too often.
2) The month routine shows a similar issue
return stats_getmidnight(strtotime(date('1-M-Y',$lastmonth).' +1 month'));
Always returns the same value for us when called from the monthly processing loop.
$timestart = $nextmonthend;
$nextmonthend = stats_get_next_monthend($timestart);
If I change the value function to read
return stats_getmidnight(strtotime('+1 month',$lastmonth));
Then it solves the infinite loop problem. I haven't checked the exact values to see if this gets me exactly one month advanced. My guess is this suffers from the same problem as above where we would get about one month difference give or take the time zone difference of some hours. Probably not enough to easily be detected as an issue.
Finally I wonder if there is some difference in how php versions process some of these string conversions. Is that possible? Our test VM is php 4.3.9, Cent OS 4.3. Our production system is running cPanel 4.4.2 and seems to have the same problems (haven't dug in as deep since it is production but has the infinite monthly loop).