Forums | Mahara Community
Support
/
upgrade mahara from 1.7.2 to 1.9.0 problem
07 May 2014, 15:43
Dear Sir,
We try to upgrade mahara from 1.7.2 to 1.9.0 version from cli or web GUI upgrade but failure
I have changed the following php.ini
max_execution_time =25000
memory_limit = 2048M
We also change the following in <<Mahara_Root>>/lib/db/upgrade.php
init_set('max_execution_time', 25000)
raise_memory_limit('2048')
When I run cli upgrade
sudo -u nobody /usr/local/bin/php <<Mahara_ROOT>>/admin/cli/upgrade.php
the following error is shown.
PHP Fatal error: Maximum execution time of 30 seconds exceeded in /local/www/mahara/lib/lib/adodb/drivers/adodb-mysqli.inc.php
It seems it is related to execution time setting except /lib/db/upgrade.php and
Please advise how and where to configure it.
William
07 May 2014, 16:22
Dear Sir,
mahara 1.9 cli upgrade log is attached.
[INF] 21 (admin/cli/upgrade.php:49) Upgrading Mahara
[INF] 21 (lib/mahara.php:221) Upgrading core
[DBG] 21 (lib/db/upgrade.php:2388) Update database for flexible page layouts feature
[DBG] 21 (lib/db/upgrade.php:2389) 1. Create table view_rows_columns
[DBG] 21 (lib/db/upgrade.php:2397) 2. Remake the table view_layout as view_layout_columns
[DBG] 21 (lib/db/upgrade.php:2406) 3. Alter table view_layout
[DBG] 21 (lib/db/upgrade.php:2418) 4. Create table view_layout_rows_columns
[DBG] 21 (lib/db/upgrade.php:2429) 5. Create table usr_custom_layout
[DBG] 21 (lib/db/upgrade.php:2439) 6. Convert existing view_layout records into new-style view_layouts with just one row
[DBG] 21 (lib/db/upgrade.php:2477) 7. Drop the obsolete view_layout.columns and view_layout.widths fields
[DBG] 21 (lib/db/upgrade.php:2484) 8. Update default values for tables view_layout, view_layout_columns and view_layout_rows_columns
[DBG] 21 (lib/db/upgrade.php:2487) 9. Update the table "block_instance"
[DBG] 21 (lib/db/upgrade.php:2515) 10. Add a "numrows" column to the views table.
[DBG] 21 (lib/db/upgrade.php:2523) 11. Update the table "view_rows_columns" for existing pages
[DBG] 21 (lib/db/upgrade.php:2881) Correcting custom layout table structures.
PHP Fatal error: Maximum execution time of 30 seconds exceeded in /local/www/mahara/lib/adodb/adodb.inc.php on line 1089
William
07 May 2014, 16:46
Hi Willian,
That is pretty strange. Right at the top of lib/db/upgrade.php, there's a command to set max_execution_time to 120 seconds. So I don't know why it would be erroring out at 30 seconds.
Are you running PHP in safe mode? The PHP manual indicates that in safe mode you can't change this setting. http://www.php.net/manual/en/info.configuration.php#ini.max-execution-time
Cheers,
Aaron
07 May 2014, 17:33
Dear Araon,
I also run phpinfo();
can confirm max_execution_time is 25000
07 May 2014, 18:42
Well, the error that you posted above is from running the command-line PHP. Possibly that's using a different php.ini file than your PHP Apache module is using. Try doing this:
php -r "phpinfo();"
... and see what your safe_mode and max_execution_time are.
07 May 2014, 20:00
Dear ,
after run php -r "phpinfo();"
max_execution_time = 0
safe_mode = off
07 May 2014, 21:04
Dear Sir,
I find that upgrade is okay when
First upgrade from 1.7.2 to 1.8.2,
Then upgrade from 1.8.2 to 1.9.0.
It seems that directly upgrade from 1.7.2 to 1.9.0 is not worked.
Please advise
William
09 May 2014, 11:05
Well, based on what you've posted here, it appears that somehow your max_execution_time is hard-set to 30 seconds. If that's the case, then probably the reason the upgrade works when you split it into two steps, is because each of those two steps takes less than 30 seconds.
The 1.7.2 -> 1.9.0 upgrade process runs exactly the same code as the 1.7.2 -> 1.8.2 -> 1.9.0 upgrade process, so if it works for you then I recommend just going with that.
Cheers,
Aaron
05 December 2020, 18:41
Teensy bit late to this particular party, but this thread comes up in searches, so for anyone else who gets bitten by the 30 second limit, which can happen if you've got a lot of stuff in Mahara, here's what's going on.
If you're running PHP on the command line, it usually has no time limit, as confirmed by the information posted above. Your max_execution_time doesn't normally get mysteriously set to 30 seconds by invisible forces. To check it:
$ php -i | grep max_execution_time
max_execution_time => 0 => 0
What is explicitly set to 30 seconds is a bunch of stuff in Mahara's lib/db/upgrade.php, which overrides any max_execution_time setting you might have. You can check this with
$ grep 'set_time_limit' /path/to/mahara/htdocs/lib/db/upgrade.php
set_time_limit(30);
(and so on...)
The original post was about Mahara 1.9 and you can see it in this case here, but this time limit is still in versions of upgrade.php as of this post.
So how do you get around it? Here are a couple of options (there may be others).
Option 1: Rinse and repeat. Despite the old adage about being crazy if you do the same thing again and expect something different to happen, it can sometimes appear to work. In this case, upgrade.php is looping through a bunch of stuff. If you've got a million thingies in your database to get through and doing 200,000 of them takes 30 seconds, it'll fail. But 200,000 of them got done. If you keep running upgrade.php with the -f switch, it'll keep chewing through them. I've had to run some upgrades four or five times to get there. It's a bit unnerving to see your upgrade "fail", though, without any useful info as to why. But, hey, you got this far, so before you roll back and try yet again, why not swing a few more times? But still, doing it this way seems a bit yucky; it'd be nice if it just worked.
Option 2: Hack Patch the upgrade script, solving your problem before it starts. A command line way to hack/patch the file in one line:
sed -i 's/set_time_limit(30)/set_time_limit(120)/' /path/to/mahara/htdocs/lib/db/upgrade.php
Or you can open lib/db/upgrade.php in a text editor and do a find for "set_time_limit(30)" and replace with "set_time_limit(120)" or the limit of your choice. (In my case I used 300 seconds. it took nearly 4 minutes to get through Mahara 19.10 upgrade's "Fixing skins for new format options" section.)
This changes every set_time_limit() in the file, which is a bit scattergun, but it should be mostly harmless (almost everything does complete in 30 seconds) and it saves you studying the file to find which one is causing your problem.
This was about command line upgrades, but the same thing applies to web UI upgrades. The difference is that there is a max_execution_time setting in your php.ini, but it's irrelevant because upgrade.php's hard-coded 30 second limit will override it anyway. If things are going to take a long time, though, try to use the command line because this factors out various kinds of timeout issues that can creep in if you're doing it in a browser.
- «Previous page
- 1
- 2
- »Next page