23 November 2010, 19:42

Steve, nothing's been changed in rebuild_artefact_parent_cache_complete since 1.3.1, so unfortunately upgrading won't help.  We need to track down the bug in that function first.  It shouldn't be deleting those parent relationships if they're still there in the artefact table.

Does anything appear in the cron log when that function runs?

23 November 2010, 21:52

I can't access the cron log, but I did find this in the error log:

[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.

23 November 2010, 22:36

I've changed the way my cron is run from curl to php. This appears to have fixed the problem, and I'm no longer getting the access denied error messages.

24 November 2010, 8:11

Steve:
       I'm pretty desperate to have this problem resolved. Can you tell me what you did to make this change? Thanks.
                 Jeff

24 November 2010, 15:30

Jeffrey,

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.

29 November 2010, 12:28

Richard:
       I  have not gotten cron to spit out any love for ol' dad here. Windows' Task Scheduler says it's being executed, but I'm not sure. Here's the entry into Task Scheduler I have...

[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.

29 November 2010, 16:15

...sorry...solved the cron log problem (Task Scheduler strips out log file output redirects), so I'm now staring at a regular repeating error...

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.

29 November 2010, 17:21

You might be running cron as the wrong user, it should be running as the webserver user.

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:

http://mahara.org/interaction/forum/topic.php?id=2241

24 November 2010, 15:51

Jeff,

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.

25 November 2010, 12:33

Steve/Richard:
       I think I might be working at a disadvantage since I'm Windows based, though, the good news is, I have access to the entire box without reservation (I have local god status on the server). PHP memory_limit is currently set to 256m, which I'm assuming would make that problem less likely. I can make changes in the overall config stuff, as long as it doesn't perturb the overall box (it's a Mahoodle install).
       I have not found any cron error logs, but I'm darned if I know where to look. The instructions for cron setup are different for me, since I'm using Windows Task Scheduler to run it. My scheduler command is...

"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.