Last modified: 2013-11-20 23:46:46 UTC
localcopy_a711e74b7da8-1.tif at 385 mb as a sample, left in /tmp on mw1208. These filled up tmpfs recently. We've got between 1 and 3 from within the last hour on all the api hosts so it looks like they are produced pretty regularly.
In eval.php: $be = FileBackendGroup::singleton()->get( 'local-multiwrite' ); $path = 'mwstore://local-multiwrite/local-public/6/67/Keith_22_nov_1988_1359Z.jpg'; $tf = $be->getLocalReference( array( 'src' => $path ) ); var_dump( $tf->getPath() ); var_dump( stat( $tf->getPath() ) ); exit; ...this prints some stat info and a path, e.g: string(33) "/tmp/localcopy_bf6f8afcb908-1.jpg" When I "ls -l" the path I get: ls: cannot access /tmp/localcopy_bf6f8afcb908-1.jpg: No such file or directory The same happens if I throw an Exception instead of calling "exit". Maybe some circular refs with TempFSFile in some caller might cause this (though gc_enabled() returns true). The other possibility would be fatal errors.
I did check for fatals from around the same time as one of those files on a given hosts and came up empty-handed, fwiw.
Could also be unlink() failures (which are not logged), though those should be exceedingly rare.
On mw1204, /var/log/apache2.log: Nov 20 18:09:49 mw1204 apache2[24246]: PHP Warning: require() [<a href='function.require'>function.require</a>]: GC cache entry '/usr/local/apache/common-local/php-1.23wmf3/includes/filebackend/TempFSFile.php' (dev=2049 ino=26479532) was on gc-list for 601 seconds in /usr/local/apache/common-local/php-1.23wmf3/includes/AutoLoader.php on line 1209 Nov 20 18:09:49 mw1204 apache2[24246]: PHP Warning: require() [<a href='function.require'>function.require</a>]: GC cache entry '/usr/local/apache/common-local/php-1.23wmf3/includes/filebackend/FSFile.php' (dev=2049 ino=26479522) was on gc-list for 601 seconds in /usr/local/apache/common-local/php-1.23wmf3/includes/AutoLoader.php on line 1209 18:09:49 - 601 seconds = ~17:59. There's tif file with that mtime in /tmp: localcopy_ff83cbc7427e-1.tif.
That suggests segfaults or other such errors. Of course those won't be in the fatal log.
*** This bug has been marked as a duplicate of bug 55541 ***
