When I follow the link I find;
- each course seems to stall at a different point
- every backup stalls on different course, (but never more than two or three.)
The courses don't appear to have anything in common.
A previous thread talks about rebuilding tables, which I have done via phpmyadmin, but the problem remains.
Another thread suggests a timeout issue. This may be the case as the only other problem I've had with Moodle is a quiz that appeared too long, IE It wouldn't load till I broke it in two.
Can someone please help? Is this likely to be the problem, where do I go to fix it?
Any clues would be appreciated.
Summary
==================================================
Courses: 33
OK: 30
Error: 0
Unfinished: 3
Some of your courses weren't saved!!
I have started to experience the same problem over the last week, though always on the same course (1 of 3). Looking at the logs, the automated backup appears to stall at a different point each time. Manual backups execute without a problem.
Any ideas?
Regards
John
Hi,
What versions are you using? There was a similar problem that was fixed back in 1.4.1. If you are using an old version you should upgrade.
Also, check to see whether the issue relates to your zip program. In the past I have had the problem twice. In the site variables page, put in path info for zip and unzip instead of leaving it blank (for my Redhat system I put in /usr/bin/zip and /usr/bin/unzip - it may be different on your system).
HTH,
Tim.
Hi Tim
I am using 1.4.3
I don't suppose it is zip programme related in my case as I can do a manual backup with no problem at all.
I am guessing it is a time out issue as it seems to show and end time of 15 mins after start after the failure whereas a successful backup is < 1 minute. I have no idea why it should be causing a time out though ;-(
Thanks
Regards
John
Hi
Since upgrading to Moodle 1.4.3 last week I am getting very similar results that tell me my backups are failing.
Likjewise I would also like to see a resolution.
Regards
Mike Taylor
Update 16/02/05 - Now 2 out of 3 courses are not backing up successfuly overnight.
Has any one got any idea what may be causing this?
J
- I'm using version 1.4.3
- I've had no problems manually backing up the same courses.
- I'm running Redhat on a virtual dedicated server
Time-out sounds the most plausible but you'd think that the courses with the most in them, would be effected the most, but this is not the case.
It's possible the load on my virtual system changes, but I've otherwise not found it that variable.
I am wondering if this may be cron related. I am getting a message that my 15 minute cron fails at backup time
Looking up planning4profit.com
planning4profit.com
Making HTTP connection to planning4profit.com Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Unexpected network read error; connection aborted.
Can't Access `http://planning4profit.com/courses/admin/cron.php'
Alert!: Unable to access document.
lynx: Can't access startfile
This is clutching at straws, but could the cron be interfering with automatic back ups?
J
premature end of script headers
on my admin/cron.php file
Exactly at the time of backup.
I too am getting similiar errors, but not every night. Most nights all courses are backed up properly, but occasionally I get an error message. In checking the logs, it appears the errors occurs after zipping the files. It doesn't complete the next steps shown below from an OK back-up.
Jim
01:32 AM:46 | zipping files |
01:32 AM:54 | copying backup |
01:32 AM:55 | cleaning temp data |
01:32 AM:55 | Phase 3: Deleting old backup files: |
01:32 AM:55 | checking c:\moodlebackup |
01:32 AM:55 | found 11 backup files |
01:32 AM:55 | keep limit (10) reached. Deleting old files |
01:32 AM:55 | backup-de-nbcc-20050403-0132.zip deleted |
01:32 AM:55 | End backup course Educational Technology at NBCC Woodstock - OK |
Are you using the resident php zip/unzip or specifying the path of the routines on your server? (see detailed settings)
Sometimes the php zip/unzip routines use more memory than php is allowed to use if the course they are backing up is large. So as Tim Allen recommends above, in my installation this problem was solved by asking my sysadmin for the paths to the zip/unzip routines on the server and then specifying them in the site settings.
Admittedly though, if manual backup works then scheduled backup should work as well. Hmm...Perhaps when using the scheduled backup the site is attempting to multi-task, so that more than one backup is going on at once? That does not sound likely. But all the same, I would recommend specifying the zip program path.
Timothy
Hi Tim,
I'm somewhat new to Moodle. Could you tell me where/how to set the paths for zip/unzip in the site settings. I've been able to manually backup courses, but when using the automatic backup with cron, the process hangs when it gets to the zipping phase.
Thanks
Curtis
Dear Curtis,
I guess you are asking Tim Allen but, the zip/unzip settings are in the detailed "configuration" settings on the main admin page or at the URL:
http://yourdoman/moodle/admin/config.php
And only your sysadmin or provider knows the path to the zip unzip, and I guess that a lot of rental servers may not let you use it, but you might try
/usr/local/bin/zip
/usr/local/bin/unzip
Good luck
Timothy
Thanks for your response. I use the basic (?) Backup feature of Moodle, with the default settings, and the path to the server (c://moodlebackup). I changed the time of the backups but still receive the occassional error (at least once a week).
The attached screen shot shows where the error occued, and it seems to be the same course that experiences the failure.
I will change the default settings to the following to see if this has any effect:
Users: Course (rather than all users).
Keep: 5 (rather than the 10 I initially set)
Thanks,
Jim
Has anyone come up with a solution to this? I'm currently running Moodle on two servers with different courses. Once server with 53 (big) courses and one with 48 short courses. Both servers are identical in config and services. I have absolutely no problems with backing up the server with 53 courses but the one with 48 always hangs end is unable to finish backups. I'm running 1.4.3+ on both servers. Problem started when I created a template course on the server with 48 courses and then deleted the course. Since then I've been unable to (automatically) backup the courses. I have no problems when I backup the courses manually. Please help!!!
Al Ortiz
My Moodle has 5 courses. Manual backups work great. Automatic/scheduled backups fail ~85% of the time.
First some background information:
The problems started in 1.3.x and continued in 1.4.3 for awhile. I upgraded to 1.5.1 and then 1.5.2 and the problem continued.
In an attempt to resolve this issue, I deleted the old installation of Moodle and removed all related databases. I performed a clean installation of 1.5.2 and then restored the courses.
Every ~8 minutes, I run:
lynx -connect_timeout=300 -dump http://www.constructiveteacher.com/admin/cron.php > /dev/null via the CRON daemon.
(I just recently added the -connect_timeout=300 string to see if that would resolve the problem - it did not)
When an automatic backup fails, I receive this email from the CRON Daemon at my webhost (Total Choice).
----------------------------------------------------------
Looking up www.constructiveteacher.com
www.constructiveteacher.com
Making HTTP connection to www.constructiveteacher.com
Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Unexpected network read error; connection aborted.
Can't Access `http://www.constructiveteacher.com/admin/cron.php'
lynx: Can't access startfile
At this point, I can no longer manually run the cron process. ../admin/cron.php reports that a Backup is in progress for the next ~45 minutes or so when I load that page in my web browser.
I've tried some different user suggestions that I've read.
- I changed the backup directory to /moodledata/globalbackups/ instead of the individual course directories. This did not seem to help.
- I manually set the path to zip / gzip in the Moodle config. This did not affect the problem.
Click on a folder icon to navigate.
Click on a name to view its properties.
/ mdata / globalbackups / (Current Folder)
backup-biology_1-20050729-0826.zip 42986 k 2777
backup-cteacher-20050729-0826.zip 92 k 2777
backup-life_science_1-20050729-0826.zip 7152 k 2777
backup-ls_-_1-20050729-0828.zip 16 k 2777
The problem usually occurs on the biology backup - it's the 43MB backup. Perhaps that has something to do with it? It occasionally fails on life_science as well - the 7MB backup.
Work Around
If I change the moodle config to not include the course files, the backups are significantly smaller - all are less than 500k. When I do this, the backups very rarely fail - only ~5% of the time or less.
Then I just have to remember to do a manual backup every now and then to make sure that the course content has been backed up.
Also, I haven't thoroughly tested this, but if I use my web browser to call /admin/cron.php instead of the CRON Daemon, a full backup fails much less frequently. I'd say a full backup is successful ~25%+ of the time.
Has anyone determined the cause of this? There seems to be some random element involved...
Caleb Benefiel
------------------------------
Today was an interesting day!
I think I've finally found a solution to the infamous...
-----------------------------------------------
HTTP request sent; waiting for response.
Alert!: Unexpected network read error; connection aborted.
Can't Access `http://www.constructiveteache
Alert!: Unable to access document.
lynx: Can't access startfile
-----------------------------------------------
...error!
I had a feeling this was a Lynx related problem, but it was hard to tell. From doing some google searches, I found that the average Lynx timeout was ~110 seconds. For some reason that I do not understand, this timeout is a bit variable. That could be why the problem starts out as an occasional problem and then gradually happens more and more often as your Moodle grows. (on a bad Lynx day, the timeout can be as low as 25 seconds).
So... why use Lynx anyway?
I guess some hosts do not allow you to directly call the PHP binary. But Total Choice Hosting does let you call PHP. On my server it's kept in /usr/local/bin/php
So, I altered my CRON process to call:
/usr/local/bin/php /home3/constea/public_html/admin/cron.php > /dev/null
And the problem seemed to go away.
I let 3 complete backups run over the course of a couple hours to make sure it wasn't just a fluke that this fixed the problem.
And I also have implemented all the suggestions I mentioned in the previous thread, so some of those changes could be contributing to this success.
Good luck if you're having this problem!
Caleb Benefiel