Using SVN192pro, I experienced and endless loop in native CLI runs when the backing up of a database is included in the profile indicated to the cron job.
The loop begins before the Back Up Administrator Table even opens a new record. In addition the log file continuously fills up with a repetition of the following lines:
[100724 22:50:03] *** Batching of engine steps finished. I will now return control to the caller.
[100724 22:50:03] Sleeping for 1999.253988266 msec, using usleep()
[100724 22:50:05] Saving Kettenrad instance cli
[100724 22:50:05] Kettenrad :: Attempting to load from database
[100724 22:50:05] -- Loaded stored Akeeba Factory
[100724 22:50:05] *** Batching of engine steps finished. I will now return control to the caller.
[100724 22:50:05] Sleeping for 1999.3131160736 msec, using usleep()
[100724 22:50:07] Saving Kettenrad instance cli
[100724 22:50:07] Kettenrad :: Attempting to load from database
[100724 22:50:07] -- Loaded stored Akeeba Factory
and so on endlessly
The only way I could break the server out of the loop was to rename the tmp folder causing a runtime error.
As this problem did not occur on every run I tested (setting up several profiles), I ran quite a number of tests and in the end was able to identify:
1. The problem only occurred in profiles that included a database backup (i.e not in "files only" profiles).
2. That if the active profile in the backend Akeeba interface did not include a database in the definitions, then the cron job for a profile that included a database would enter the endless loop. Alternately if the active profile in the back end was that of a profile that included a database (i.e full site bu), then the cron job would run OK even if it was not for the same profile.
I was logged into the back end while the cron jobs ran.
I hope this helps flush out a bug.
David
The loop begins before the Back Up Administrator Table even opens a new record. In addition the log file continuously fills up with a repetition of the following lines:
[100724 22:50:03] *** Batching of engine steps finished. I will now return control to the caller.
[100724 22:50:03] Sleeping for 1999.253988266 msec, using usleep()
[100724 22:50:05] Saving Kettenrad instance cli
[100724 22:50:05] Kettenrad :: Attempting to load from database
[100724 22:50:05] -- Loaded stored Akeeba Factory
[100724 22:50:05] *** Batching of engine steps finished. I will now return control to the caller.
[100724 22:50:05] Sleeping for 1999.3131160736 msec, using usleep()
[100724 22:50:07] Saving Kettenrad instance cli
[100724 22:50:07] Kettenrad :: Attempting to load from database
[100724 22:50:07] -- Loaded stored Akeeba Factory
and so on endlessly
The only way I could break the server out of the loop was to rename the tmp folder causing a runtime error.
As this problem did not occur on every run I tested (setting up several profiles), I ran quite a number of tests and in the end was able to identify:
1. The problem only occurred in profiles that included a database backup (i.e not in "files only" profiles).
2. That if the active profile in the backend Akeeba interface did not include a database in the definitions, then the cron job for a profile that included a database would enter the endless loop. Alternately if the active profile in the back end was that of a profile that included a database (i.e full site bu), then the cron job would run OK even if it was not for the same profile.
I was logged into the back end while the cron jobs ran.
I hope this helps flush out a bug.
David
