Though someone else had a similar problem recently, and said they *were* running cron as the webserver user and it still wasn't writable, so take a look at this thread too:
]]>Just out of interest: was your site working fine and then developed this problem, or could it have been happening since installation?
]]>Your defined data root directory, E:\maharadata\, is not writable. This means that neither session data, user files nor anything else that needs to be uploaded can be saved on your server. Please make the directory if it does not exist, or give ownership of the directory to the web server user if it does.
...which is not accurate. The data directory DOES exist, has been written to thousands of times by the Mahara install itself. Not sure what cron thinks is different.
]]>[path to program files])\PHP\php-win.exe -f [path to Mahara install]\lib\cron.php >> [path to log folder]\mahara-cron.log
The thing is scheduled to run every 1 minute for a "duration" of 1 day. The log is NOT getting written to. To test the command, I built a bat file. It DOES create the log file, but doesn't write anything to it.
]]>Jeff
]]>For one of the artefacts that is in /home/parentfolder/subfolder, ascertain its ID (from its URL in the view) and run the following query on your database
SELECT * FROM `artefact_parent_cache` where artefact = ID
When I do this I get back one entry: with the 'parent' being the ID of the subfolder. This corresponds with the id in the URL you see when you mouseover the subfolder name in My Files. Then try:
SELECT * FROM `artefact_parent_cache` where artefact = subfolderID
What do you get back? You should get an entry with the 'parent' being the ID of the parentfolder. If you're not getting this then for some reason Mahara isn't writing that entry to the database, and that's what's breaking your site.
I suggest you make sure the bug is reported at https://bugs.launchpad.net/mahara. I can't see this bug in the list, and I'd consider it to be at least of medium importance.
]]>]]>
I cured it by altering the raise_memory_limit() in cron.php, raising it to 256M fixed the problem for us.
]]>You should be able to confirm if cron is breaking your site by creating a new view containing just a new folder of files (don't use an exisiting folder, just create one at top level and drop a couple of files into it). If you can download the files in that view OK straight after creation, and then come back to it after rebuild_artefact_parent_complete runs to find the 'access denied' errors, then that function is breaking your site.
The explanation you gave earlier in this thread points to this being the problem. Can you confirm this at least?
]]>"D:\Program Files (x86)\PHP\php-win.exe" -f [local path to Mahara]\lib\cron.php
...which I swiped from the Moodle instructions on running cron from Windows. Windows says it's running successfully, but I ain't buying it, since the problems are still there. I have no idea how to change the command to force curl to handle it, or to direct where to write errors. PHP error logs show no out of memory errors. I'm getting a LOT of errors, but nothing that seems to specifically reference cron or the data points discussed here.
I did make the DB changes you suggested, Steve, and then ran cron from the task scheduler directly. Nothing has changed...still "access denied" errors, and no change to the PHP error log.
Again, I'm not anything like an expert here, but I can follow directions, and I do sincerely appreciate your attempts to help me with this.
As Richard says, you could try changing the way your cron runs (if that is what is also causing your headaches). What I did was temporarily change the frequency of rebuild_artefact_parent_cache_complete in the cron table so that it ran every five minutes and also changed the nextrun value to something in the next few minutes. Then I was able to tail the error_log in /lib and see that PHP was running out of memory. I can't change that in php.ini or via .htaccess so I had a go at running the cron via PHP (instead of curl), and that fixed things up straight away. This might seem counter-intuitive, but it worked.
I'm not sure if this will be a long-term solution for us, but I'm just glad things are back to normal for now. The problem, I think, is down to a combination of the size of our artefact table, our PHP memory limit, and the way in which rebuild_artefact_parent_cache_complete function runs.
Hope this helps.
Steve.
]]>Do you have the cron log yet, and if so, do you see any of those 'out of memory' errors?
You could try what Steve did (change from php to curl, see http://wiki.mahara.org/System_Administrator%27s_Guide/Cron_Job), but that might not help you (he had a fixed PHP memory limit of 64M).
If it's too hard to get the cron log, a potential advantage of changing to curl, even if temporarily, is that cron errors would be spat out into the webserver log, which might help in finding out what's going on.
]]>This might be the same as the problem reported here: https://bugs.launchpad.net/mahara/+bug/680710
]]>[23-Nov-2010 21:40:01] [DBG] c2 (lib/cron.php:70) ---------- cron running Tue, 23 Nov 2010 21:40:01 -0600 ----------
[23-Nov-2010 21:40:01] [DBG] c2 (lib/cron.php:149) Running core cron rebuild_artefact_parent_cache_dirty
[23-Nov-2010 21:40:01] [DBG] c2 (lib/cron.php:149) Running core cron rebuild_artefact_parent_cache_complete
[23-Nov-2010 21:40:12] PHP Fatal error: Out of memory (allocated 58982400) (tried to allocate 4864 bytes) in /public_html/lib/dml.php(46) : runtime-created function on line 1
The out of memory error looks like it's happening a few seconds after every time rebuild_artefact_parent_cache_complete is run. I have a PHP memory limit of 64M, which I cannot change.
]]>Does anything appear in the cron log when that function runs?
]]>