Page MenuHomePhabricator

update.php fails with SQLite
Closed, DeclinedPublic

Description

Author: tmt

Description:
While trying to run php maintenance/update.php on a wiki that uses SQLite database, instead of doing the update the script returns:

MediaWiki 1.17.0 Updater

DB connection error: Cannot return last error, no db connection

The required database update isn't done, tested with extension(s) and without.

Tested on following setup:

MediaWiki 1.17.0
PHP 5.2.6-1+lenny13 (cgi-fcgi)
SQLite 3.5.9 with full-text search support


Version: 1.17.x
Severity: normal

Details

Reference
bz31696

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:47 PM
bzimport added a project: MediaWiki-Rdbms.
bzimport set Reference to bz31696.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Oct 14 2011, 2:19 PM
brion added a comment.Oct 14 2011, 8:44 PM

Can the updaters even work on sqlite? ALTER TABLE is pretty much limited to adding new fields...

http://www.sqlite.org/lang_altertable.html

Yes it can. As the matter of fact, unit tests verify this on every run even if $wgDBtype is not "sqlite":) We have to work around cases where we need DROP COLUMN, of course:)

brion added a comment.Oct 15 2011, 7:54 PM

Ok, confirmed w/ Max that we expect the updaters to generally work; things like drop column are worked around by duplicating data to a temporary table, then swapping it back in place.

So this is probably a fairly specific problem: perhaps incorrect path so it's not loading properly, or something closing out the connection (which ought not happen :) in the middle of the updates.

Jussi, what was the previous version of MW that you're updating from? We can try updating the same versions and see if this happens for us...

Probably also worth double-checking contents of your LocalSettings.php to make sure that paths and settings are correct and nothing changed unexpectedly.

tmt wrote:

(In reply to comment #3)

Ok, confirmed w/ Max that we expect the updaters to generally work; things like
drop column are worked around by duplicating data to a temporary table, then
swapping it back in place.
So this is probably a fairly specific problem: perhaps incorrect path so it's
not loading properly, or something closing out the connection (which ought not
happen :) in the middle of the updates.
Jussi, what was the previous version of MW that you're updating from? We can
try updating the same versions and see if this happens for us...
Probably also worth double-checking contents of your LocalSettings.php to make
sure that paths and settings are correct and nothing changed unexpectedly.

This is a mediawiki that was installed as 1.17.0, and I tried to run the update.php so I could finalize the install of liquidthreads extension (svn). The wiki works just fine otherwise, but I can provide my settings if its needed.

Ow, LiquidThreads.... Could you confirm that everything works if LQT is disabled?

tmt wrote:

(In reply to comment #5)

Ow, LiquidThreads.... Could you confirm that everything works if LQT is
disabled?

Yup, did test and got the same result (error), hence the "tested with extension(s) and without" in the original message. (:

when you say without extensions, do you mean you removed the LQT folder or just
disabled it in LocalSettings?

tmt wrote:

(In reply to comment #7)

when you say without extensions, do you mean you removed the LQT folder or just
disabled it in LocalSettings?

Latter, now I tested with (re)moving the extension folder contents so there's none, and still the same error. Something else I should try?

This is probably a permissions failure. Could you run the command line script with the same user as the one who runs the web server? Alternatively, see http://www.mediawiki.org/wiki/Extension:Maintenance_scripts

(In reply to comment #9)

Alternatively, see
http://www.mediawiki.org/wiki/Extension:Maintenance_scripts

Please do not recommend that or any other "maintenance" extension. Maintenance scripts are meant to be run from the command line only.

tmt wrote:

(In reply to comment #9)

This is probably a permissions failure. Could you run the command line script
with the same user as the one who runs the web server? Alternatively, see
http://www.mediawiki.org/wiki/Extension:Maintenance_scripts

Could you elaborate what kind of permission failure this would be? As my shell user is the owner of the database file, and as far as I know (which isn't much) it's the only permission management with sqlite.

(In reply to comment #11)

Could you elaborate what kind of permission failure this would be? As my shell
user is the owner of the database file, and as far as I know (which isn't much)
it's the only permission management with sqlite.

I was only saying that because it looked like the sort of problem I would run into when the file was owned by "www-data" (my web server user) and I ran as "mah". If you own the DB file, then I don't think it is the permissions problem.

sumanah wrote:

We discussed this bug in IRC today. Max Semenik said, "I would love to see a repro for this bug...looks like the connection is getting closed somewhere."

DJ Bauch, whom I am now cc'ing on the bug, said, "I may try to reproduce since I probably face similar / same issues with MSSQL". I'm asking him to reproduce this sometime in the next few days, since we want it fixed before the official MediaWiki 1.18.0 release.

I've tried several times to reproduce the problem tonight. I don't think this is a problem with 1.18 and I couldn't reproduce it with 1.17.

I tried the running update.php after each of the following scenarios:

1.16 -> 1.17
1.17 -> add LQT from 1.17 branch
-> add LQT from svn
-> 1.18 with LQT from svn

My config for each of these tests:

$ dpkg -l php5-sqlite php5-cli
...
ii libapache2-mod-php5 5.3.8-1~dotdeb.2 server-side, HTML-embedded scripting language (Apache 2 module)
ii php5-cli 5.3.8-1~dotdeb.2 command-line interpreter for the php5 scripting language
ii php5-sqlite 5.3.8-1~dotdeb.2 SQLite module for php5

Not enough information to reproduce.