Connection loss with a failure to reconnect led to a variety of failure
modes, such as an assertion from getBindingHandle() when addQuotes() is
next called. And Maintenance::shutdown() was calling
commitPrimaryChanges() three times, each call leading to an assertion
due to the round stage being broken.
So, try to exit promptly if a DBConnectionError is caught, by
introducing a new "reached" category for fatal exceptions. Guard the
calls to commitPrimaryChanges(), and skip the call prior to shutdown()
since shutdown() calls it already.
Change-Id: I81ee9017a58adac674a9495802f6bd4bcc22ee61
This reverts commit 4f7a4a2477.
Reason for revert: This change is good, just need some preparation in extensions.
Depends-On: I24221be2cedfa132fc94d39d72e4a133cc3cdb12
Depends-On: I5e6119b650e581c6aa5a1132aa071b49cff8b8ca
Change-Id: I5a5a9000751fa3914c9d432eb49475091b3bdb80
Maintenance scripts often need to manipulate configuration settings.
This introduces a way to do this cleanly via SettingsBuilder,
removing the need to rely on global variables.
Bug: T294739
Bug: T294742
Bug: T300128
Change-Id: Ibf443fd564bbbf388cce8ab4dabba55ebca0dfa4
Returning void from execute() is success.
Returning true is success, false is failure with exit(1)
Using fatalError also using exit(1)
Change-Id: I1d40430ad6226e4aab8f0810b03ee1213282d123
Currently all the signal constants emit warnings as they are undefined
in PHP 7.4 and throw fatal error in PHP 8, if pcntl is not available.
pcntl extension is not enabled by default, and is not required by
MediaWiki, so this class should throw a better error if it's not
found. The class already has comment that pcntl and posix are required
but this is meaningless since the error and a warning for each constant
would be emitted anyway.
https://www.php.net/manual/en/pcntl.installation.php
Convert RESTARTABLE_SIGNALS constant back to static property as it was,
because we can only use these constants after confirming they exist,
which happens in the constructor.
Bug: T280456
Change-Id: I66deaa9b346b936b2628ac0511492d20a42fea6c
Many files were in the autoloader despite having potentially harmful
file-scope code.
* Exclude all CommandLineInc maintenance scripts from the autoloader.
* Introduce "NO_AUTOLOAD" tag which excludes the file containing it
from the autoloader. Use it on CommandLineInc.php and a few
suspicious-looking files without classes in case they are refactored
to add classes in the future.
* Add a test which parses all non-PSR4 class files and confirms that
they do not contain dangerous file-scope code. It's slow (15s) but
its results were enlightening.
* Several maintenance scripts define constants in the file scope,
intending to modify the behaviour of MediaWiki. Either move the
define() to a later setup function, or protect with NO_AUTOLOAD.
* Use require_once consistently with Maintenance.php and
doMaintenance.php, per the original convention which is supposed to
allow one maintenance script to use the class of another maintenance
script. Using require breaks autoloading of these maintenance class
files.
* When Maintenance.php is included, check if MediaWiki has already
started, and if so, return early. Revert the fix for T250003 which
is incompatible with this safety measure. Hopefully it was superseded
by splitting out the class file.
* In runScript.php add a redundant PHP_SAPI check since it does some
things in file-scope code before any other check will be run.
* Change the if(false) class_alias(...) to something more hackish and
more compatible with the new test.
* Some site-related scripts found Maintenance.php in a non-standard way.
Use the standard way.
* fileOpPerfTest.php called error_reporting(). Probably debugging code
left in; removed.
* Moved mediawiki.compress.7z registration from the class file to the
caller.
Change-Id: I1b1be90343a5ab678df6f1b1bdd03319dcf6537f
Additional code cleanup:
* Call setCacheTime() in parseAndStash instead of relying
on the one in DerivedPageDataUpdater.
* Improve the SPI logging by adding more extra fields.
* Treat requests in CLI/job mode (aside from tests) like
those from bots with regard to checking the stash.
This should avoid stats/logging pollution.
Change-Id: I8c6be919e399378e401a60502add0ecec7764d2d
Deprecate the second argument to Maintenance::error() in favor of a new
Maintenance::fatalError() method. This is intended to make it easier to
review flow control in maintenance scripts.
Change-Id: I75699008638f7e99b11210c7bb9e2e131fca7c9e
This lets the runJobs.php $wgCommandLineMode hack be removed.
Some fixes based on unit tests:
* Only call applyTransactionRoundFlags() for master connections
for transaction rounds from beginMasterChanges().
* Also cleaned up the commitAndWaitForReplication() reset logic.
* Removed deprecated DataUpdate::doUpdate() calls from jobs
since they cannot nest in a transaction round.
Change-Id: Ia9b91f539dc11a5c05bdac4bcd99d6615c4dc48d
It is now very easy to implement a simple low delay job runner:
while true; do php runJobs.php --wait; sleep 1; done;
Change-Id: I50cf00aed4b15d90384a2cc12bddd64d96d5a1ad
Move the MWLogger PSR-3 logging related classes into the
MediaWiki\Logger namespace. Create shim classes to ease migration of
existing MWLoggerFactory usage to the namespaced classes.
Bug: T93406
Change-Id: I359cc81fbd2dcf8937742311dcc7d3dee08747b0
* Also added an async flag to SpecialRunJobs so that it can be
set to false to get a JSON blob back with a regular 200 status.
Change-Id: I2f5763e017684c3c61f3d3f27ddf7f7834bdfce2
* The new job loop already manages timeouts and this version caused
some problems with the time-sharing approach that used --maxtime.
This killed runners too fast for some jobs and only handled CPU
time anyway, not wall clock time.
Change-Id: Id3462554b1ecba9ecdf7d49673645d54c0555cd6
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I727deec35a712de0f0c676cc87dfa661f1ee965b
If there is an unhandled exception during a job, rollback the
transaction to be safe. Otherwise its likely that the
transaction will be commited when next job is run, as $dbw->begin()
implicitly commits any open pending transactions. This can result
in database referential integrity issues.
Change-Id: I5807e64440ff6c6651fbbb4924645d05d843b98e
* Previously, it did not if --type was used
* A --nothrottle option was added to ignore throttling
Change-Id: Ib3ca899f1ce30250a63084096f1b660c96e359fe
Shouldn't be needed and aren't for any core operations. If any
extension relies on these $wgTitles being set in maintenance
environments those extensions are broken and should be fixed.
Change-Id: Ie02a5042ab96e155d783d56d5340dd0da8e3d55c
* This also adds a Job::workItemCount() method
* Removed unused USE_PRIORITY constant
* A few small cleanups in runJobs.php
Change-Id: Ife9370e488fa63dcd1f702ed98f3b7f26057f10c
We had a comment at the top of runJobs.php listing potential options to
use. That unsurprisingly ended up being outdated. Instead folks should
either:
* page down to the constructor to have the exhaustive list of options
* RTFM by invoking the script with --help
Change-Id: Ic87574b26145376bb9926894a7c35f9f0622a3e9
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
