Page MenuHomePhabricator

Install hangs after Creating tables... in database
Closed, InvalidPublic

Description

Author: aramatev

Description:
When I try to install mediawiki it stops after the line "Creating tables..."

Here is the info before install.



Checking environment...

Please include all of the lines below when reporting installation problems.

  • PHP 5.1.4 installed
  • Found database drivers for: MySQL * Warning: PHP's register_globals option is enabled. Disable it if you can. MediaWiki will work, but your server is more exposed to PHP-based security vulnerabilities.
  • PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
  • Have XML / Latin1-UTF-8 conversion support.
  • Warning: A value for session.save_path has not been set in PHP.ini. If the default value causes problems with saving session data, set it to a valid path which is read/write/execute for the user your web server is running under.
  • PHP is configured with no memory_limit.
  • Couldn't find Turck MMCache, eAccelerator, or APC. Object caching functions cannot be used.
  • Found GNU diff3: /usr/bin/diff3.
  • Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if you enable uploads.
  • Found GD graphics library built-in.
  • Installation directory: /home/ohillfr/public_html/greenwiki
  • Script URI path: /greenwiki
  • Environment checked. You can install MediaWiki. ******** ********

Here is the info after install is run.



Checking environment...

Please include all of the lines below when reporting installation problems.

  • PHP 5.1.4 installed
  • Found database drivers for: MySQL * Warning: PHP's register_globals option is enabled. Disable it if you can. MediaWiki will work, but your server is more exposed to PHP-based security vulnerabilities.
  • PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
  • Have XML / Latin1-UTF-8 conversion support.
  • Warning: A value for session.save_path has not been set in PHP.ini. If the default value causes problems with saving session data, set it to a valid path which is read/write/execute for the user your web server is running under.
  • PHP is configured with no memory_limit.
  • Couldn't find Turck MMCache, eAccelerator, or APC. Object caching functions cannot be used.
  • Found GNU diff3: /usr/bin/diff3.
  • Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if you enable uploads.
  • Found GD graphics library built-in.
  • Installation directory: /home/ohillfr/public_html/greenwiki
  • Script URI path: /greenwiki
  • Environment checked. You can install MediaWiki. *

    Generating configuration file...
  • Database type: MySQL
  • Loading class: DatabaseMysql
  • Attempting to connect to database server as ohillfr_wikiusr...success.
  • Connected to 4.1.22-standard
  • Database ohillfr_wikidb exists
  • Creating tables... ******** ********

I have traced down the problem to 2 lines inside /config/index.php

FIXME: Check for errors

			print "<li>Creating tables...";
			if ($conf->DBtype == 'mysql') {
				dbsource( "../maintenance/tables.sql", $wgDatabase );
				dbsource( "../maintenance/interwiki.sql", $wgDatabase );
			} else if ($conf->DBtype == 'postgres') {
				$wgDatabase->setup_database();
			}
			else {
				$errs["DBtype"] = "Do not know how to handle database type '$conf->DBtype'";
				continue;
			}

it successfully runs tables.sql, then hangs when it hits interwiki.sql.
I have looked inside the file and the REPLACE INTO seems to have correct syntax.
Also when I simply run the sql statements in interwiki.sql against the db, they all run.
When i place the sql lines in interwiki.sql inside tables.sql, they also run.
So I'm not sure why the script would hang there on trying to run interwiki.sql
So perhaps dbsource() defined inside install-utils.inc in root dir has some issues ?
I noticed the file does not have a .php extension.. I'm not sure how much my server likes that.
But maybe that does not matter because the file starts with < ? php. However i did notice all other php files in the root folder have extension .php.
Or maybe thats because they are meant to be accessed directly while install-utils.inc is only an include file.

In any case I'm completely bewildered why my install will not go through.
I have installed mediawiki just fine on my own personal machine, but are having this particular issue when I try to install it on my online server. It is on shared hosting but php and mysql are installed properly and mediawiki recognizes the environment to be OK.

please help
thank you


Version: 1.10.x
Severity: normal
OS: Linux
Platform: Other

Details

Reference
bz10862

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:49 PM
bzimport set Reference to bz10862.
bzimport added a subscriber: Unknown Object (MLST).

aramatev wrote:

After it hanged at Creating tables.
I hit refresh because I saw the script (config/index.php) takes this into account and will try to update and move on.

The script hung again.. this time while doing update call with do_all_updates() on line "Deleting old default messages (this may take a long time!)...", the function is found inside updaters.inc.



Checking environment...

Please include all of the lines below when reporting installation problems.

  • PHP 5.1.4 installed
  • Found database drivers for: MySQL * Warning: PHP's register_globals option is enabled. Disable it if you can. MediaWiki will work, but your server is more exposed to PHP-based security vulnerabilities.
  • PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
  • Have XML / Latin1-UTF-8 conversion support.
  • Warning: A value for session.save_path has not been set in PHP.ini. If the default value causes problems with saving session data, set it to a valid path which is read/write/execute for the user your web server is running under.
  • PHP is configured with no memory_limit.
  • Couldn't find Turck MMCache, eAccelerator, or APC. Object caching functions cannot be used.
  • Found GNU diff3: /usr/bin/diff3.
  • Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if you enable uploads.
  • Found GD graphics library built-in.
  • Installation directory: /home/ohillfr/public_html/greenwiki
  • Script URI path: /greenwiki
  • Environment checked. You can install MediaWiki. *

    Generating configuration file...
  • Database type: MySQL
  • Loading class: DatabaseMysql
  • Attempting to connect to database server as ohillfr_wikiusr...success.
  • Connected to 4.1.22-standard
  • Database ohillfr_wikidb exists
  • There are already MediaWiki tables in this database. Checking if updates are needed...

...hitcounter table already exists.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...logging table already exists.
...user_newtalk table already exists.
...transcache table already exists.
...trackbacks table already exists.
...externallinks table already exists.
...job table already exists.
...langlinks table already exists.
...querycache_info table already exists.
...filearchive table already exists.
...querycachetwo table already exists.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...have rc_type field in recentchanges table.
...have rc_ip field in recentchanges table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...have rc_old_len field in recentchanges table.
...have user_real_name field in user table.
...have user_token field in user table.
...have user_email_token field in user table.
...have user_registration field in user table.
...have log_params field in logging table.
...have ar_rev_id field in archive table.
...have ar_text_id field in archive table.
...have page_len field in page table.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have img_media_type field in image table.
...have ss_total_pages field in site_stats table.
...have iw_trans field in interwiki table.
...have ipb_range_start field in ipblocks table.
...have ss_images field in site_stats table.
...have ipb_anon_only field in ipblocks table.
...have ipb_enable_autoblock field in ipblocks table.
...have user_newpass_time field in user table.
...have user_editcount field in user table.
...have rc_deleted field in recentchanges table.
...have log_id field in logging table.
...have log_deleted field in logging table.
...have ar_deleted field in archive table.
...have ipb_deleted field in ipblocks table.
...have fa_deleted field in filearchive table.
...have rev_len field in revision table.
...have ar_len field in archive table.
...have rev_parent_id field in revision table.
...have pr_id field in page_restrictions table.
...already have interwiki table
...indexes seem up to 20031107 standards
Already have pagelinks; skipping old links table updates.
...image primary key already set.
The watchlist table is already set up for email notification.
...watchlist talk page rows already present
...user table does not contain old email authentication field.
Logging table has correct title encoding.
...page table already exists.
revision timestamp indexes already up to 2005-03-13
...rev_text_id already in place.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...already have pagelinks table.
...templatelinks table already exists
No img_type field in image table; Good.
Already have unique user_name index.
...user_groups table already exists.
user_groups is in bogus intermediate format. Renaming to user_groups_bogus... ok
Re-adding fresh user_groups table... ok


  • WARNING: You will need to manually fix up user permissions in the user_groups
  • table. Old 1.5 alpha versions did some pretty funky stuff... ***

...wl_notificationtimestamp is already nullable.
...timestamp key on logging already exists.
Setting page_random to a random value on rows where it equals 0...changed 0 rows
Checking for additional recent changes indices...
...index on ( rc_namespace, rc_user_text ) seems to be ok
...index on ( rc_user_text, rc_timestamp ) seems to be ok
...redirect table already exists.
Checking for backlinking indices...
Checking if pagelinks index pl_namespace includes field pl_from...
...index pl_namespace on table pagelinks seems to be ok
Checking if templatelinks index tl_namespace includes field tl_from...
...index tl_namespace on table templatelinks seems to be ok
Checking if imagelinks index il_to includes field il_from...
...index il_to on table imagelinks seems to be ok
...page_restrictions table already exists.
Deleting old default messages (this may take a long time!)...



So the function ends with the following code lines:
echo "Deleting old default messages (this may take a long time!)..."; flush();
deleteDefaultMessages();
echo "Done\n"; flush();

do_stats_init(); flush();

if( $purge ) {

		purge_cache();
		flush();

}

and you can see that Done was never printed. Thus it hung on the function call deleteDefaultMessages();

The function deleteDefaultMessages() found inside /maintenance/deleteDefaultMessages.php calls on a Default user defined in the user_group. I assume this is where the script stops because the tables were never initialized. So this 'MediaWiki default' does not yet exist. Or maybe i dont particularly understand what the User::newFromName() call actually does with 'MediaWiki default' user.

function deleteDefaultMessages() {
$user = 'MediaWiki default';
$reason = 'No longer required';

global $wgUser;
$wgUser = User::newFromName( $user );
$wgUser->addGroup( 'bot' );

$dbr = wfGetDB( DB_SLAVE );
$res = $dbr->select( array( 'page', 'revision' ),

		array( 'page_namespace', 'page_title' ),
		array(
			'page_namespace' => NS_MEDIAWIKI,
			'page_latest=rev_id',
			'rev_user_text' => 'MediaWiki default',
		)

);

Anyway, any ideas?

aramatev wrote:

I tried to hit refresh again, just out of curiosity what it will do. I get the following.



No img_type field in image table; Good.
Already have unique user_name index.
...user_groups table already exists.
user_groups is in bogus intermediate format. Renaming to user_groups_bogus... ok
Re-adding fresh user_groups table... Query "CREATE TABLE user_groups (
ug_user int unsigned NOT NULL default '0',
ug_group varbinary(16) NOT NULL default '',
PRIMARY KEY (ug_user,ug_group),
KEY (ug_group)
) TYPE=InnoDB
" failed with error code "Table 'user_groups' already exists (localhost)".



It tried renaming the user_groups to user_groups_bogus.. but i think that table already existed.. so it did nothing. and when it went to create group user_groups. it fails.
I am sure this is what occured because i went back and deleted user_groups_bogus. and hit refresh yet again.. and this time again it stalls just as before at the line.. "Deleting old default messages (this may take a long time!)..."

jimhu wrote:

Failure at deleteDefaultMessages also happens on OSX Server on a G5. The error message is (unknown). I suspect that somewhere in the install sequence, the installer has 'localhost' hardcoded for mySQL user creation instead of using the host name from the form. I was able to get around this by commenting out the call to this function. In the end, the installation did not create a WikiSysop User, but I suspect that is due to a different bug.

Gah, closed the wrong bug...

The actual bug reported in comment 0 that it hung was the issue, but that could've been caused by any number of issues. Refreshing constantly just caused it to fail unpredictably at various stages of the installer (evidenced via the following information).

Doesn't surprise me that the old installer was so subject to problems refreshing...it didn't handle error checking terribly well.

Closing this INVALID, since there's not really enough information here to be actionable on. Chances are it's not present in the new-installer, which will be a part of 1.17.