Forums | Mahara Community

Support /
upgrade mahara from 1.7.2 to 1.9.0 problem


anonymous profile picture
Account deleted
Posts: 23

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

anonymous profile picture
Account deleted
Posts: 23

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

Aaron Wells's profile picture
Posts: 896

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

anonymous profile picture
Account deleted
Posts: 23

07 May 2014, 17:33

Dear Araon,

I also run phpinfo();

can confirm max_execution_time is 25000

anonymous profile picture
Account deleted
Posts: 23
Aaron Wells's profile picture
Posts: 896

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.

anonymous profile picture
Account deleted
Posts: 23

07 May 2014, 20:00

Dear ,

after run php -r "phpinfo();"

max_execution_time = 0

safe_mode = off

anonymous profile picture
Account deleted
Posts: 23

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

 

Aaron Wells's profile picture
Posts: 896

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

Marcus Leonard's profile picture
Posts: 6

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.

12 results