Moodle

Are the following messages related to the above?

Error message /admin/cron.php (via browser):
Checking automated backup status...RUNNING
automated backup are already running. Execution delayed

Error message /admin/cli/automated_backups.php (via commandline):
Checking automated backup status...RUNNING
automated backups are already. If this script is being run by cron this constitues an error. You will need to increase the time between executions within cron.
Automated cron backups completed correctly
Cryptic last line because nothing happens

Getting this issue too, I can force the backup to run if I change a return value in the get_automated_backup_state function in backup/util/helper/backup_cron_helper.class.php

Haven't been able to track down how Moodle is determining if the backup is running yet, but the comment in the code is interesting - does the functionality exist yet?

I've included the function with the modification to force the backup to run (after the backup started running for me I reverted the code).

/**

• Gets the state of the automated backup system.
  *
• @global moodle_database $DB
• @return int One of self::STATE_*
  */
  public static function get_automated_backup_state($rundirective = self::RUN_ON_SCHEDULE) {
  global $DB;

$config = get_config('backup');
$active = (int)$config->backup_auto_active;
if ($active === self::AUTO_BACKUP_DISABLED || ($rundirective == self::RUN_ON_SCHEDULE && $active === self::AUTO_BACKUP_MANUAL)) { return self::STATE_DISABLED; } else if (!empty($config->backup_auto_running)) { // TODO: We should find some way of checking whether the automated // backup has infact finished. In 1.9 this was being done by checking // the log entries. # return self::STATE_RUNNING; return self::STATE_OK; }
return self::STATE_OK;
}

Ok - I am running in Linux and I have been trying and trying to get this to run. Here is my code - can you help me figure out what to change? - I have tried commenting out, setting mtrace('RUNNING') to OK, various other issues but to no avail - I have been testing using automated_backups.php in cli - I can see where the changes I make are effecting (e.g. If I change text, it changes, so know that I am in the right place) but just can't seem to get the backup to actually initialize:

mtrace("Checking automated backup status",'...');
$state = backup_cron_automated_helper::get_automated_backup_state($rundirective);
if ($state === backup_cron_automated_helper::STATE_DISABLED) { mtrace('INACTIVE'); return $state; } else if ($state === backup_cron_automated_helper::STATE_RUNNING) {
mtrace('RUNNING');
if ($rundirective == self::RUN_IMMEDIATLY) { mtrace('automated backups are already. If this script is being run by cron this con$ } else { mtrace("automated backup are already running. Execution delayed"); }
return $state;
} else { mtrace('OK'); }
backup_cron_automated_helper::set_state_running();

I have the same problem, cron is showing this:
Checking automated backup status...RUNNING
automated backup are already running. Execution delayed

But backup hasn't been running for over a month...

I have found that if I force backups to run once (as in James Yale's comment) and change the code back afterwards, then if they don't get unexpectedly interrupted on a subsequent run (by, for example, running out of disk space - see #MDL-25863) they continue to work.

Obviously not a real solution - the key lies in the comment about "we should find some way of determining if the backup is in fact finished" - yes, and that should have been designed in in the first place. What it's doing to see that the backup is still running is looking at the value recorded in the database that says "this is running now".

In my case the whole backup system doesn't work - even when i try manually backup a course it displays an empty page...
So I tried to edit the backup_cron_helper.class.php file as mentioned above. It wasn't wroking, so I edited the code to this:
/**

• Gets the state of the automated backup system.
  *
• @global moodle_database $DB
• @return int One of self::STATE_*
  */
  public static function get_automated_backup_state($rundirective = self::RUN_ON_SCHEDULE) { return self::STATE_OK; }

then I ran cron.php and then I reverted back the change ... and everything is now working... strange issue.
Maybe it's caused by a failed backup before migrating to 2.0 - I didn't get a backup confirmation email a week before migrating to 2.0

I am still struggling with the code. I don't know if maybe I have a newer version but I have tried changing out various lines and nothing works.
This is how my code reads - I have tried replacing the run_automated_backup with your suggestion as well as get_automated_backup_state. I have tried commenting out various parts in an attempt to bypass the checking automated state altogether.
I would really appreciate any help. I am just starting with php and while I am starting to understand the general layout of the code, I am really not ready to write it!!

I have this running live and have had no backups in a month - if my teachers find out they will probably kill me!!

/**

• Runs the automated backups if required
  *
• @global moodle_database $DB
  */
  public static function run_automated_backup($rundirective = self::RUN_ON_SCHEDULE) {
  global $CFG, $DB;

$status = true;
$emailpending = false;
$now = time();

mtrace("Checking automated backup status",'...');
$state = backup_cron_automated_helper::get_automated_backup_state($rundirective);
if ($state === backup_cron_automated_helper::STATE_DISABLED) { mtrace('INACTIVE'); return $state; } else if ($state === backup_cron_automated_helper::STATE_RUNNING) {
mtrace('RUNNING');
if ($rundirective == self::RUN_IMMEDIATLY) { mtrace('automated backups are already. If this script is being run by cron this cons$ } else { mtrace("automated backup are already running. Execution delayed"); }
return $state;
} else { mtrace('OK'); }
backup_cron_automated_helper::set_state_running();

The other thought is that it has to be now be pulling the State_Running from somewhere in the database, I am presuming. Is there not a way to go in to the database and just change the setting from Running to Ready to Backup?

We had the same problem and we solved it with a workaround, after a little of code exploration for understanding its behaviour.
We removed the entry in the table mdl_config_plugins (where 'mdl_' is the table prefix for our installation). The query is something like:
delete from mdl_config_plugins where name like "backup_auto_running"
Even if the state is not fully coherent (in other tables there are the entries for the backups of single courses with state unfinished or uncorrect), after that operation the backup procedure should restart to work (almost this is our experience)...

The code that determines if the backup is running already states that this is an unreliable way of determining if there is a running instance, by the way
HTH.

THANK YOU!!!! Running a backup right now! What a relief.

This worked for me to, here are the queries used for easier reference of anyone finding the bug:

SELECT * FROM `<database_name>`.`mdl_config_plugins` WHERE `name` LIKE 'backup_auto_running'

Then rather than removing the row I set the value back to 0:

UPDATE `<database_name>`.`mdl_config_plugins` SET `value` = '0' WHERE `mdl_config_plugins`.`name` = 'backup_auto_running' LIMIT 1;

Yet to determine if this fixes the backup yet though, last time I changed it the backup started running again but the value of this field still seemed to not get reset after the backup completed.

Yeah – this is a definite bug...and the worst part is that if you're not paying attention to your backups, you're not going to notice until you have a problem, and then it will be too late.

I have one course that keeps hanging and sending this deal back to the auto backup running consistently. Is there anyway to exclude a course from the automated backup?

For those of you who don't want to play around with your database. You can work around the problem by adding

set_config('backup_auto_running', '0', 'backup'); after line 243 (Which is //Everything is finished stop backup_auto_running) to the file backup/util/helper/backup_cron_helper.class.php

Sorry, something hit me today and I went back and checked my notes and while I initially added it after line 243, that didn't work and I moved that line to 74 (along with a few other places, but I left it there, which was bad). I hope I didn't cause anyone too much grief.
To be clear though – this isn't a fix – it is just a workaround for those of you who don't want to mess with your DB. It just resets the flag in the MySQL database that will then allow the backups to run. Do this on a large site, and you'll get lots of simultaneous processes running with unrestricted resource use – you'll likely crash your server if a site backup takes much longer than your cron interval. In short, I want to unpost my last post.
Sorry!

So where exactly is the best place to put the line - Line 74? My line 74 is

if ($state === backup_cron_automated_helper::STATE_DISABLED) {
mtrace('INACTIVE');

Is that right? I would think we would either want to set that at the end of the backup (which might be an issue if the backup does not complete properly) or at the beginning.

I ended up adding this line right before the file checks the auto backup status and it works like a charm - thanks.

Previous workaround!
Where exactly to place what?

backup/util/helper/backup_cron_helper.class.php is the file to be adjusted.

I placed the line
set_config('backup_auto_running', '0', 'backup');
Immediately before the line

trace("Checking automated backup status",'...');

That worked for me.

Have had the same problem myself. I believe it was caused by 3 massive scorm courses being uploaded! 100MB +

@Luca Mazzola @James Yale, thank you very much indeed. I discovered this morning while attempting to move the backups to another server, that there weren't any, and I couldn't get them to run either. :o Your help has allowed me to start the backup process (now to wait ~36 hours to see if it completes!).

Ho,

the backup_auto_running is one semaphore (in DB) that we use to prevent multiple simultaneous executions of the automated backups.

Under Moodle 1.9 we used to look for automated backup activity by looking to the backup logs table and, if no activity was found in XX minutes, it was assumed that the process had ended with error and the semaphore was cleaned to allow next executions to work.

But that check os recent activity is something that we lost in the move to Moodle 2.0 so, once one automated backup execution failed, the semaphore was never cleared, leading to the situations reported here.

What we have done is to (re-introduce) the check again, by looking for activity in the backup_controllers table, so, if no activity is detected in 90 mins, the semaphore will be cleaned and new automated backup executions will be allowed.

Hope it helps, ciao

(oops, edited branches, previous ones were incorrect)

Not sure if this is the right place, but our auto backup fails when it hits a course containing a scorm object, and of course the flag in the db isn't reset, so it doesn't try again, as discussed above.

I've traced a cause of this failure (at least on IIS/MSSQL, running ms native driver) to backup_structure_dbops_class,
public static function move_annotations_to_final($backupid, $itemname)

for some reason, when it hits
$DB->set_field('backup_ids_temp', 'itemname', $itemname . 'final', array('id' => $annotation->id));

the query it sends
"UPDATE #mdl_backup_ids_temp SET itemname = N'filefinal' WHERE id = '3'"

doesn't return, doesn't complete, doesn't error. Eventually the process gets killed by the web server.

I did find that adding a timeout to the database do_query function in sqlsrv_native_moodle_database
$result = sqlsrv_query($this->sqlsrv, $sql,array(),array('QueryTimeout'=>5));

at least returns an error. rather than just hanging indefinitely.

Hi Gregor, can I suggest you creating a new issue for that problem? Please report as much info as possible (versions, how to reproduce it...). Initially I'd recommend you to update to latest Moodle 2.0.x+ release, because it some changes have happened in our impl. of the native sqlsrv driver (not sure if related or no, perhaps you could also try to run all the DB unit tests in your server to see if they detect something).

In any case, let's discuss that in another issue, plz and tia!

Ciao

Thanks Eloy integrated now

Works Great
Thanks for providing the fix, Eloy.

All git & cvs servers have been updated with these cool changes, so closing, many thanks!

Thanks to all working on this issue!

Thanks Eloy, I've updated to the latest Moodle, the issue has changed . Will post a tracker entry once I've figured out what I can.

This is marked as closed but I'm setting seeing the issue on a recently upgraded Moodle 2.2.1+ where the backup_auto_running flag isn't being cleared on the database after a backup run - is there another bug related to it?

edit: Nevermind, it's fixed itself, can't find a way to delete this comment!