Last modified: 2013-04-02 10:05:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27975 - maintenance/update.php fails with "Access denied; you need the SUPER,REPLICATION CLIENT privilege for this operation"
maintenance/update.php fails with "Access denied; you need the SUPER,REPLICAT...
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2011-03-10 16:57 UTC by James Paige
Modified: 2013-04-02 10:05 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description James Paige 2011-03-10 16:57:06 UTC
I have a mediawiki installation which has been working perfectly for many months.

I installed from svn. Each night I have a script that runs

    svn update

This week it suddenly started failing with the following error:

...have iw_api field in interwiki table.
...iwl_prefix key doesn't exist.
...iwl_prefix_from_title key doesn't exist.
...have cl_collation field in categorylinks table.
...categorylinks up-to-date.
Fixing collation for 51 rows.
Processing next 50 rows... 0 done.
A database query syntax error has occurred.
The last attempted database query was:
from within function "DatabaseBase::getMasterPos".
Database returned error "1227: Access denied; you need the SUPER,REPLICATION CLIENT privilege for this operation ("

I have not made any recent changes to my LocalSettings.php
Comment 1 James Paige 2011-03-10 17:02:43 UTC
By searching through recent svn revisions, i have found that this problem started with revision 83529

james_paige@ravenwest:~/$ svn log -v -r 83529
r83529 | catrope | 2011-03-08 08:47:26 -0800 (Tue, 08 Mar 2011) | 4 lines
Changed paths:
   M /trunk/phase3/includes/db/LoadBalancer.php
   M /trunk/phase3/maintenance/updateCollation.php

Make updateCollation.php a bit less murderous for WMF databases:
* Don't run a COUNT(*) query on what's potentially the entire categorylinks table on enwiki (hundreds of millions of rows). Put it in a miser mode check
* Wait for DB replication to catch up before processing the next batch. Implemented LoadBalancer::waitAll() for this purpose, which should behave more nicely than wfWaitForSlaves()


I should note that I do not use replication or load balancing, and I have never configured anything related to masters or slaves.
Comment 2 Max Semenik 2011-03-10 17:11:38 UTC
Roan, ping.


Quick grepping indicates that updateCollation is the only maint script that is likely to be run in a non-replicated environment and uses getMasterPos().
Comment 3 Antoine "hashar" Musso (WMF) 2011-03-11 17:15:24 UTC
r83529 marked fixme.
Comment 4 Roan Kattouw 2011-03-14 09:31:25 UTC
Fixed in r83874.
Comment 5 James Paige 2011-03-14 17:37:06 UTC
I can confirm that the problem is fixed on my wiki. Thanks!
Comment 6 Liangent 2013-03-30 19:24:03 UTC
Reopening -- The solution fails on Toolserver (with a MediaWiki configured to use replicated database). It really has two LB-configured database servers: one for global blocking stuff and another for everything else. There's no replication relationship between them (of course) but wfWaitForSlaves() is misled by the server count and tries to do something then fails.

liangent@nightshade:~/code/gerrit/mediawiki/core$ php maintenance/eval.php --wiki=zhwiki_p
> $lb = wfGetLB();

> print_r($lb->getServerInfo(0));
    [host] => sql-s2-user
    [user] => liangent
    [password] => ********
    [dbname] => zhwiki_p
    [type] => ts
    [load] => 1
    [groupLoads] => Array
            [globalblocking] => 0

    [flags] => 16

> print_r($lb->getServerInfo(1));
    [host] => centralauth-p.rrdb
    [user] => liangent
    [password] => ********
    [dbname] => centralauth_p
    [type] => ts
    [load] => 0
    [groupLoads] => Array
            [globalblocking] => 1

    [flags] => 16

Comment 7 Liangent 2013-03-30 19:26:24 UTC
Generally speaking (not to talk about Toolserver), this still happens to users without replication-related stuff configured, but with GlobalBlocking (or anything else who uses LB to connect to a second database server) configured.
Comment 8 Andre Klapper 2013-04-02 08:48:58 UTC
Liangent: In general it's better to file a new ticket than reopening one that was closed two years ago, in order to get attention.
Comment 9 Liangent 2013-04-02 10:05:20 UTC
(In reply to comment #8)
> Liangent: In general it's better to file a new ticket than reopening one that
> was closed two years ago, in order to get attention.

Should I re-mark this bug as fixed, then create a new one?

Note You need to log in before you can comment on or make changes to this bug.