Statistics is currently in catchup mode. So far 1 day(s) have been processed and 10 are pending. Check back soon!
The thing is statistics are always in catchup mode on the site and I can't work out how to force it to catch up.
This specifies how far back the logs should be processed the first time the cronjob wants to process statistics. If you have a lot of traffic and are on shared hosting, it's probably not a good idea to go too far back, as it could take a long time to run and be quite resource intensive. (Note that for this setting, 1 month = 28 days. In the graphs and reports generated, 1 month = 1 calendar month.)
Stats processing can be quite intensive, so use a combination of this field and the next one to specify when it will run and how long for.
What time should the cronjob that does the stats processing start?
I have been playing with the variables but they don't seem to make much difference. I am still one day complete with 12 pending now. Obviously the script must have ran at least once at the start but I'm still not convinced that it is doing anything now The traffic on my site isn't huge (~500 hits daily average).
Currently my settings are yes, all, until complete, 00:00 and 0 but I have tried other combinations.
run this query:
select * from mdl_config where name like '%stats%';
(this will give a few more pieces of information)
and change the start time to 1am and see if that makes a difference.
Yes, wait til the 1am one goes and then see.
Also, look for the output of cron, it should stay stuff like
'starting daily statistics gathering...'
and then print some dates and tell you what it's doing and how many days it has done.
I changed the time to 00:30 and triggered it manually just after (a few times) and nothing about stats appeared in the list. Also tried at 35 and 40 and still no mention.
Interestingly I have a test site on a different server / network and I tried that (latest nightly also). Cron hadn't been run on it for many days and I got 'starting daily statistics gathering...' at the bottom the first time and that was it - nothing else (same variables as mentioned earlier). I changed the time on the test server and triggered cron manually at 00:30 and I got a stale lock error in the cron list! I changed the times again in line with the above tests on the test server and 'starting daily statistics gathering...' has not appeared on the list since and the number of days remained the same
select count(*) from mdl_stats_daily;
select count(distinct(timeend)) from mdl_stats_daily;
and if you have skype, it might be easier to discuss this over IM.
The site I am using is not live, and no-one is using the database, but I have a lot of data from the 19th of April and before. I, too, am in catch up mode, have processed 0 days and have 14 days pending. When I initially ran the cron manually it kept giving me errors on modules - dialogue, exercise, hotpot and then book. I deleted all these one by one and reset the config variables. The last time I ran cron it just hung on Running daily statistics gathering... There is still nothing in any of my stats tables.
It is trying to look 2 weeks back (so there is a week worths of live data from 200 courses). I ran it two hours ago and the config fields look like this:
Any help appreciated.
When I run the cron now I do have the stale lock on:
I still am catch up mode, have processed 0 days and have 14 days pending.
And the data looks like:
If I go to stats from the front page I get the same catch up mode statement with no data in any of my stats tables.
php version? database type and version? anything in the database error log?
Moodle 1.6 Beta3
I've had a little look at this and as far as I can tell there seems to be two problems (+1):
From function stats_check_uptodate in /lib/statslib.php I understand we are going to throw up the message we are in catch up mode if:
1. it is not 2 days before the date we want to get statistics:
2. days pending is equal to zero and we havent processed any days:
return true; // we've only just started...
(my days pending is 14 and my days done 0)
So basically if I enter that function I will throw that error. This seems wrong. * Presumably this should be greater than.
If I override those checks and return true from that function I get There is no available data to display, sorry. This, I think, is a different problem.
This is caused by earliestday, week, month using todays date as the stats tables are empty. This means that timeoptions is null because nothing is set in function stats_get_time_options as none of the below type statements are true.
$timeoptions[STATS_TIME_LASTWEEK] = get_string('numweeks','moodle',1);
If I enter a valid earliestday,month, year I get a page from which i can search statistics. I use this to search it tells me that stats.php does not exist, which is a third problem I think I saw this problem in the bug tracker.
Does all this make sense?
I don't know about stats.php being missing, I wrote stats a while ago and all the reporting related files were moved around afterwards. If you could point to the bug tracker # that would be helpful.
Are you running cron from command line php or from wget/curl? If you're using wget/curl can you check the apache error log?
Also, can you check the mysql error log? You may need to increase the error reporting level, I can't help there, I purged all mysql knowledge when I discovered postgres.
I think the form action should be 'index.php' not 'stats.php', but I'll have a look into this tommorrow.
>I think the code in that function is corerct, but the problem is that you have no data in your stats table.
Seems to me that there should be a clause that accounts for a first pass where the stats table isn't filled or the possibilty that for some reason the stats table is empty, no?
Are you running cron from command line php or from wget/curl?
cron from browser window - admin/cron.php
Also, can you check the mysql error log?
Will look tommorrow, but its a new server with a new administrator so I am not sure.
> stats table isn't filled or the possibilty that for some reason the stats table is empty,
Why? If enablestats is on, and there is no data, it means that (unless there's a problem occuring as in this case, which there shouldn't be!), stats has JUST been set to run, but there's no data. Therefore, stats is in 'catchup mode'.
Bear in mind that if you have a big site, and you want to set stats to start running over ALL the logs, it will take a long time to catch up.
When we first enabled stats in our biggest installation (50,000 users, 10,000 courses and a year of logs), we had it set to run, I think 6 hours a night, and it took about 2 weeks to process all the history and catch up to itself.
This is by no means on a slow server ;)
> cron from browser window - admin/cron.php
You're running it manually? Ok, at any rate if you're running it through the browser, please check your apache error log.
> Will look tommorrow, but its a new server with a new administrator so I am not sure.
Great! Keep me posted.
I installed to the latest version (previously I was working on one I downloaded on the 19th Apr) and it all works.
Thanks for your support!
I have been reading through this post and indeed get the same errors in catchup mode. I have run some of the queries suggested, and was wondering if you would have an idea as to what the issue may be...
I am running moodle 1.6.4 on a Linux server with mysql db...
I will run the commands tomorrow and get back to you here (real busy tonight) in case it helps anybody else. Beyond that I will add you to skype and try and get in touch over the next couple of days.
I have two installs running the latest 1.6 Beta 5 (2006050504) on a linux box running PHP5 and MySql 4.1.14.
Both installs have the problem of being in catchup mode (one says it has processed 9 days with 73 pending, the other 1 day has been processed with 57 pending).
Both have stale lockfiles e.g. for one of them it says:
STALE LOCKFILE FOR statsrunning - was 1148911980
Running daily statistics gathering...
starting at 1144418400Have run the queries Penny mentioned in other posts in this thread (see attached).
Any pointers would be much appreciated.
how many courses do you have?
you say you're running the latest 1.6 beta but is that what you were running when you _started_ running stats?
can you run ps ax | grep cron and paste the output here?
are you running cron with wget or with php cli?
Can you also run
select count(*) from mdl_stats_weekly;
select count(*) from mdl_stats_monthly;
select count(*) from mdl_stats_user_daily;
select count(*) from mdl_stats_user_weekly;
select count(*) from mdl_stats_user_monthly;
How's life across the water? Thanks for popping in
The screen shots are actually from the install that has only processed 1 day with 58 pending (guessing that's not good!)
The install in question only has 9 courses and 8 members. Both of the 1.6 installs I have minimal data; one was just to have a look at 1.6 when the beta was first released, this one is just being set up for collabaration between various organisations and as such is not live yet (the courses and members are for demo purposes on Wednesday and have virtually no data in them other than topic headings and a couple of blocks).
Both installs where fresh 1.6 Beta from just before SourceForge went down, both are now up-to-date as of yesterday (been keeping an eye on it to see if any bug fixes would fix it up since initial install but sadly no).
No worries . . . ummmmm . . . can you give me a bit more of a hint on what that means (sorry, a lot of this coding/linux/php/sql stuff is still Greek to me )
At the moment on these installs just firing them manually, either via the admin page within moodle or direct in the browser (been firing them from the admin page and then half a dozen or so tries direct to see if they would catch up). When setup properly it will be run via php I believe (wget doesn't work on my hosted server, all the current cron jobs I have setup on live Moodle installs and other scripts start with"php -q $HOME/public_html/" etc.)
See below for screen shots of the queries you mentioned . . . in fact no need for an attachment - they are all 0. Was just about to crop them and attach when I noticed the results all being 0?
delete from mdl_stats_daily;
delete from mdl_config where name like '%stats%';
and then set your admin options again and try again. I know I fixed an infinite loop bug awhile ago, but I'm worried about the fact you're using php 5.
Do you still have php 4 on your system? try from the command line:
and if you have that, you can run moodle cron like
and that way it won't time out.
Did the two deletions and fired cron again, same deal - 1 day processed, 58 remaining.
Switched back to PHP 4.4.1 (at my host, both are still running, PHP 4 being default, just added "AddHandler application/x-httpd-php5 .php" to the .htaccess file to switch to PHP 5) and then did the two deletions again, fired cron a few times - same results.
Have my admin options set to:
enablestats = yes
statsfirstrun = all
statsmaxruntime = until complete
statsruntimestart = 00:05
statsuserthreshold = 0
No error logs as far as I can see.
I will try and reproduce this today if I have time.
Running statistics cron through apache is generally a very bad idea though.
I really need the output of the FIRST attempt to run cron. Preferably NOT through a browser. Can you run those deletions again and run your cronjob from the command line, and paste the output here or attach it as a file or something?
You should be able to do
(php4 /path/to/cron.php 2>&1) > forpenny.txt
Cron completes fine. At the moment I can't get to the command line (have to look into a way of getting Putty to sneak through the firewall here!) but will do it when I get home and post the results.
Thanks again for you help on this
I'm running Moodle 1.6 Beta 5, mysql 5.0.18, php 5.1.2 Windows 2003 running IIS and stats are not processing
I've no results in SQL, CRON logs show no processing of Stat jobs
I've set the variable for one week and any class with 1 or more members.
I've no idea what to look at now.
The solution was to completely delete the exercise module to eliminate it as the problem and then run the SQL delete commands listed above:
delete from mdl_config where name like '%stats%';
That reset the stats data so that it started over from scratch and since then the stats have been running just fine. I don't know if this is the exact issue that other people have experienced, but I thought I'd mention it in case someone else is in a similar situation.
I have got stats to work in the reports menu but the problem lies now with the same appearing for the individual on the Activity Reports section under the Statistics tab. The image does not show up in this section and the moodle installtion is version 1.6. If I right click i get the page name as statsgraph.php. Can someone tell me what this should be and actuall the path to this page is /course/statsgraph.php but this page does not exist in the said location. Can someone point me in the direction to set this right and where to configure this missing page???