Last modified: 2014-11-11 18:32:53 UTC
This is related to bug 44850. When I run `php maintenance/update.php` to install the Flow extension, it creates temp files -rw-rw-r-- 1 spage wikidev 28 2013-08-29 06:46 /tmp/mw-UIDGenerator-UID-128 -rw-rw-r-- 1 spage wikidev 12 2013-08-29 06:46 /tmp/mw-UIDGenerator-UID-nodeid then, when I try to access a page like Special:Flow/Sandbox, PHP fails with Could not open '/tmp/mw-UIDGenerator-UID-128'. Backtrace: #0 /srv/mediawiki/includes/UIDGenerator.php(150): UIDGenerator->getTimestampAndDelay('lockFile128', 16384, 1048576) #1 /srv/mediawiki/extensions/Flow/includes/Model/UUID.php(31): UIDGenerator::newTimestampedUID128(16) #2 /srv/mediawiki/extensions/Flow/includes/Model/Workflow.php(73): Flow\Model\UUID::create() the workaround is to remove these files after running update.php It would be better if update cleaned up, or if UIDGenerator could clean up at termination it would fix bug 44850 as well.
Still current. We just got this again, on terbium, with the /usr/local/bin/characterEditStatsTranslate script for bug 58440. The script is run as mwdeploy:mwdeploy and has read permission, but not write permission, on that file, currently dated Mar 16 20:02. Warning: fopen(/tmp/mw-UIDGenerator-squidhtcppurge-48): failed to open stream: Permission denied in /usr/local/apache/common-local/php-1.23wmf18/includes/utils/UIDGenerator.php on line 296 [7e60e1e9] [no req] Exception from line 301 of /usr/local/apache/common-local/php-1.23wmf18/includes/utils/UIDGenerator.php: Could not open '/tmp/mw-UIDGenerator-squidhtcppurge-48'. Backtrace: #0 /usr/local/apache/common-local/php-1.23wmf18/includes/utils/UIDGenerator.php(247): UIDGenerator->getSequentialPerNodeIDs(string, integer, integer, integer) #1 /usr/local/apache/common-local/php-1.23wmf18/includes/deferred/SquidUpdate.php(222): UIDGenerator::newSequentialPerNodeIDs(string, integer, integer, integer) #2 /usr/local/apache/common-local/php-1.23wmf18/includes/deferred/SquidUpdate.php(145): SquidUpdate::HTCPPurge(array) #3 /usr/local/apache/common-local/php-1.23wmf18/includes/deferred/SquidUpdate.php(124): SquidUpdate::purge(array) #4 /usr/local/apache/common-local/php-1.23wmf18/includes/Title.php(3604): SquidUpdate->doUpdate() #5 /usr/local/apache/common-local/php-1.23wmf18/includes/WikiPage.php(3128): Title->purgeSquid() #6 /usr/local/apache/common-local/php-1.23wmf18/includes/WikiPage.php(2210): WikiPage::onArticleEdit(Title) #7 /usr/local/apache/common-local/php-1.23wmf18/includes/WikiPage.php(1874): WikiPage->doEditUpdates(Revision, User, array) #8 /usr/local/apache/common-local/php-1.23wmf18/maintenance/edit.php(90): WikiPage->doEditContent(WikitextContent, string, integer) #9 /usr/local/apache/common-local/php-1.23wmf18/maintenance/doMaintenance.php(104): EditCLI->execute() #10 /usr/local/apache/common-local/php-1.23wmf18/maintenance/edit.php(106): require_once(string) #11 /usr/local/apache/common-local/multiversion/MWScript.php(97): require_once(string) #12 {main}
(In reply to Nemo from comment #1) > Still current. We just got this again, on terbium, [...] The terbium issues have been resolved locally for now, let's hope that this won't come back.
Change 121549 had a related patch set uploaded by BryanDavis: Make UIDGenerator cache files world writable https://gerrit.wikimedia.org/r/121549
Change 121549 abandoned by BryanDavis: Make UIDGenerator cache files world writable Reason: Aaron and Chris are right in pointing out that this is not a good way to solve this problem. For production hosts we should never see this issue if mwscript is being used to execute all maintenance scripts. If we do have file ownership problems on a production host that can be traced to UIDGenerator cache file permissions that should be treated as toolchain problem to be resolved by ensuring that the proper wrapper scripts are being used. https://gerrit.wikimedia.org/r/121549
For production hosts we should never see this issue if mwscript is being used to execute all maintenance scripts. If we do have file ownership problems on a production host that can be traced to UIDGenerator cache file permissions that should be treated as toolchain problem to be resolved by ensuring that the proper wrapper scripts are being used. The problem S ran into looks to be on a local/vagrant/labs dev server. I think the best answer for this is to advocate good script execution hygiene. I don't know if there is a good way to enforce this programmatically, but wiki maintenance scripts should always be run as the web server user (usually www-data on Ubuntu using Apache). If you run a maintenance script as a more privileged user you run the risk of executing malicious code that could do any number of nasty things as "you".
