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".

I just tried to install Flow, and still get this locally when clicking submit on Special:EnableFlow

In T55791#2018447, @aude wrote:

I just tried to install Flow, and still get this locally when clicking submit on Special:EnableFlow

Running a maintenance script as a user that is not the web server user will cause this every time. The issue is that UIDGenerator stores local state in temp files that become owned by the user that first generates a UUID.

Using MW 1.28.2, I'm facing the same problem:

[060bc67ef212156a3ef32803] /index.php/Talk:Main_Page RuntimeException from line 442 of /var/www/includes/utils/UIDGenerator.php: Could not open '$IP/images/temp/mw-UIDGenerator-UID-88'.

Backtrace:

#0 /var/www/includes/utils/UIDGenerator.php(120): UIDGenerator->getTimeAndDelay(string, integer, integer, integer)
#1 /var/www/extensions/Flow/includes/Model/UUID.php(157): UIDGenerator::newTimestampedUID88(integer)
#2 /var/www/extensions/Flow/includes/Model/Workflow.php(157): Flow\Model\UUID::create()
#3 /var/www/extensions/Flow/includes/WorkflowLoaderFactory.php(97): Flow\Model\Workflow::create(string, Title)
#4 /var/www/extensions/Flow/includes/Actions/Action.php(105): Flow\WorkflowLoaderFactory->createWorkflowLoader(Title)
#5 /var/www/extensions/Flow/includes/Actions/ViewAction.php(20): Flow\Actions\FlowAction->showForAction(string, OutputPage)
#6 /var/www/extensions/Flow/includes/Actions/Action.php(50): Flow\Actions\ViewAction->showForAction(string)
#7 /var/www/includes/MediaWiki.php(495): Flow\Actions\FlowAction->show()
#8 /var/www/includes/MediaWiki.php(289): MediaWiki->performAction(Article, Title)
#9 /var/www/includes/MediaWiki.php(851): MediaWiki->performRequest()
#10 /var/www/includes/MediaWiki.php(512): MediaWiki->main()
#11 /var/www/index.php(43): MediaWiki->run()
#12 {main}

Even though I ran all maintenance scripts as the server user www-data which also has ownership of the temp folder. What's worse is that I can't find any file like that in the temp folder! Is there any workaround for this?

In T55791#3299343, @Calexit wrote:

Using MW 1.28.2, I'm facing the same problem:

[060bc67ef212156a3ef32803] /index.php/Talk:Main_Page RuntimeException from line 442 of /var/www/includes/utils/UIDGenerator.php: Could not open '$IP/images/temp/mw-UIDGenerator-UID-88'.

Even though I ran all maintenance scripts as the server user `www-data` which also has ownership of the temp folder. What's worse is that I can't find any file like that in the temp folder! Is there any workaround for this?

Based on the paths in the trace, the script is probably trying to open /var/www/images/temp/mw-UIDGenerator-UID-88. The error could be caused by either an existing file owned by another user or the user executing the script not having write permission to the /var/www/images/temp directory. Besides fixing the permissions on existing files/directories, $wgTmpDirectory could be changed to point to another location if that was more desirable.

We probably should have closed this bug as 'declined' years ago per the comments on https://gerrit.wikimedia.org/r/#/c/121549/.

The error could be caused by either an existing file owned by another user or the user executing the script not having write permission to the /var/www/images/temp directory

ls -al /var/www/images 
total 20
drwxrwxrwx  3 www-data www-data 4096 May 31 13:40 .
drwxr-xr-x 20 root     root     4096 May 31 13:40 ..
-rwxrwxrwx  1 www-data www-data  252 May 26 18:12 .htaccess
-rwxrwxrwx  1 www-data www-data   84 May 26 18:12 README
drwxrwxrwx  2 www-data www-data 4096 May 31 13:40 temp

ls -al /var/www/images/temp
total 8
drwxrwxrwx 2 www-data www-data 4096 May 31 13:40 .
drwxrwxrwx 3 www-data www-data 4096 May 31 13:40 ..

And I still have the same error on all talk pages!

@Calexit a little late, but fwiw I had to also run touch mw-UIDGenerator-UID-88 in the temp directory.

I got this same issue on my wiki in a VPS. Solution was to reboot the server to empty the tmp directory.

Suddenly on my wiki after the latest upgrade:

This is left sitting around after running update.php:
/tmp/mw-UIDGenerator-UID-nodeid

And this is left sitting around each day by some other process:
/tmp/mw-UIDGenerator-UUID-128

Please clean them up.

Also by the way, what if more than one wiki is installed on a shared server by more than one user?

I experienced the issue described by by @Calexit in T55791#3299344 when I wanted to move the temporary directory from the default to /var/tmp/umranica, so I did the following:

1. cp -a /srv/repo/umranica/temp to /var/tmp/umranica
2. set $wgTmpDirectory = "/var/tmp/umranica";

The permissions on both directories where identical: drwxr-sr-x www-data adm.
Attempting to open a Flow discussion page yielded:

Could not open '/var/tmp/umranica/mw-UIDGenerator-UID-88

However, when I symlinked /srv/repo/umranica/temp to /var/tmp/umranica and commented out the setting of $wgTmpDirectory it worked as expected!

My wiki runs MW 1.31.5 on 7.4.4 (apache2handler) on Ubuntu 18.04
Apache2 runs as www-data