Bug #60294

If a local file storage is outside the document root, images are sometimes not shown if multiple images are on a page.

Added by Jost Baron over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-07-13
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

This possibility was introduced with this patcheset: https://review.typo3.org/#/c/27760/

If there are many (5-10) images on a page, some of them are not shown. Maybe it is a concurrency-issue, it happens with apache and mod_php.


Related issues

Related to TYPO3 Core - Task #36420: Filemount in local file system (not on webserver) leads to errors Closed 2012-04-22
Related to TYPO3 Core - Bug #59662: Problem with subsequent calls to $configurationManager->setLocalConfigurationValueByPath and 'LocalConfiguration invalid' Closed 2014-06-19
Related to TYPO3 Core - Bug #59432: setLocalConfigurationValueByPath() writes LocalConfiguration.php on each request Rejected 2014-06-10
Related to TYPO3 Core - Bug #62301: ConfigurationManager setters make system unstable Rejected 2014-10-17
Related to TYPO3 Core - Bug #60650: ConfigurationManager::getConfigurationValueByPath ignores AdditionalConfiguration.php Closed 2014-07-29

History

#1 Updated by Markus Klein over 6 years ago

Do you have see error messages? What is generated instead of the images. I doubt this is a concurrency problem as there is no parallelism for generating images.

#2 Updated by Jost Baron over 6 years ago

I can't identify a definite error message in the log, only two candidates:

[error] [client x.y.z.w] PHP Catchable fatal error:  Argument 1 passed to TYPO3\\CMS\\Core\\Utility\\ArrayUtility::setValueByPath() must be an array, integer given, called in
/.../typo3_src-6.2.4/typo3/sysext/core/Classes/Configuration/ConfigurationManager.php on line 202 and defined in /.../typo3_src-6.2.4/typo3/sysext/core/Classes/Utility/ArrayUtility.php
on line 176, referer: [...]

[notice] child pid 8662 exit signal Bus error (7)

The used PHP-Version is the one that comes with the latest Ubuntu 12.04 LTS as mod_php.

In the frontend, there was only an empty space where the image should be - when viewing the image info, the image file was small (2 Bytes or something).

Sorry for the vague info, can't reproduce this anymore, since I've fixed it by moving the fileadmin into the document root.

#3 Updated by Jost Baron about 6 years ago

I've looked a bit more into this, it also happens in a fcgid-setup.

The problem is that the $localconfiguration retrieved in line 201 of TYPO3\CMS\Core\Configuration\ConfigurationManager is invalid. It is the integer 1. Thus the error message posted above.

The above two error messages are sometimes accompanied by this one:

[fcgid:warn] [pid 24055] [client 127.0.0.1:52844] mod_fcgid: stderr: PHP Fatal error:  Uncaught exception 'UnexpectedValueException'
with message 'LocalConfiguration invalid.' in
[...]/typo3_src-6.2.4/typo3/sysext/core/Classes/Configuration/ConfigurationManager.php:276, referer: [...]

So if I had to do a wild guess, I'd say that the LocalConfiguration is rewritten by each of the requests to an image (can confirm that), and locking does not work (maybe because its an eID script?). But I have no idea how to check if this is the actual reason, and how to fix it.

Also, some more info on my setup (had to rebuild it):

1. There is a folder "fileadmin" outside the document root
2. That folder is linked with a symlink in the document root, since otherwise TypoScript templates are not found and the install tool complains.
3. The storage record is non-hidden, has an absolute path, uses case sensitive paths, is set as default storage, the folder for temporary files is not set, is searchable, is writable, is online, but is not public. Setting it to public results in TYPO3 complaining and setting it non-public again.
4. The whole installation was updated from 4.2.

#4 Updated by Markus Klein about 6 years ago

[notice] child pid 8662 exit signal Bus error (7)

This is very weird, so there is a server problem as well.

Never heard that LocalConfiguration is rewritten all the time.

Having the storage non-public does not make sense from what you wrote.
What is the URL of the not working image?

#5 Updated by Jost Baron about 6 years ago

The image URI is /index.php?eID=dumpFile&t=p&p=149&token=f86d6f4e47afc8c040d1a79a3903c91887536699

I've looked again, when accessing the above URL the LocalConfiguration.php is at least touched, the last modification time changes. I've made sure nothing else (like the AJAX-requests from the Backend) is requesting something. I do have an AdditionalConfiguration.php-file, but its last modification was 10 days ago.

#6 Updated by Markus Klein about 6 years ago

If you access the image URL directly. What do you see?

#7 Updated by Jost Baron about 6 years ago

I see the correct image (always, but especially for the images that did not work when embedded into the page).

Also, the non-working images on a single page change with each request, seemingly at random. It does not matter if the images are cached (TYPO3 returns a 304 code) or if the images are really transferred. The response for the not working images a HTTP 500.

#8 Updated by Markus Klein about 6 years ago

Hi!

Can you please switch to Development context and enable error logs, such that we get a full trace for the PHP errors above.
The 500 errors seem to stem from these error. We need to find the dependency, which the requests seem to interfere.

#9 Updated by Markus Klein about 6 years ago

What is in your AdditionalConfiguration?

#10 Updated by Jost Baron about 6 years ago

There are no more error messages, only one I have not posted yet is this one:

[Wed Jul 23 21:11:58.037103 2014] [fcgid:warn] [pid 31189] (104)Connection reset by peer: [client 127.0.0.1:53970] mod_fcgid: error reading data from FastCGI server, referer: [...]
[Wed Jul 23 21:11:58.037190 2014] [core:error] [pid 31189] [client 127.0.0.1:53970] End of script output before headers: index.php, referer: [...]

But thats only the fcgid-equivalent of the one above with the bus error.

My AdditionalConfiguration.php contains this:

<?php
    include_once('ServerspecificConfiguration.php');

The ServerspecificConfiguration.php contains this (or something similar):

<?php
use \TYPO3\CMS\Core\Configuration\ConfigurationManager;

ConfigurationManager::setLocalConfigurationValueByPath('DB/database', 'foobar');
ConfigurationManager::setLocalConfigurationValueByPath('DB/host',     'localhost');
ConfigurationManager::setLocalConfigurationValueByPath('DB/password', 'foobar');
ConfigurationManager::setLocalConfigurationValueByPath('DB/username', 'foobar');

ConfigurationManager::setLocalConfigurationValueByPath('GFX/colorspace', 'RGB');

ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport',                'foobar');
ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_server',    'foobar');
ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_username',  'foobar');
ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_password',  '');
ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_encrypt',   '');

ConfigurationManager::setLocalConfigurationValueByPath('SYS/enableDeprecationLog', 'file');

#11 Updated by Markus Klein about 6 years ago

Ok, here we come closer to the problem why your LocalConfiguration file is rewritten all the time.

ConfigurationManager::setLocalConfigurationValueByPath() rewrites the file on EVERY call!

What you want to do is actually:

$GLOBALS['TYPO3_CONF_VARS']['DB']['database'] = 'foobar';
$GLOBALS['TYPO3_CONF_VARS']['DB']['host'] = 'host';
...

You do not want to persist this configuration, you just want to override it.

Keep in mind that the LocalConfiguration is cached and may not always be read from the file, only the AdditionalConfiguration is read everytime.

#12 Updated by Jost Baron about 6 years ago

Ok, this has solved the problem. Thanks for your time!

Shouldn't the LocalConfiguration.php be protected against concurrent write access, in case someone does a thing like I did? In that case a performance hit would occur since requests become serialized, but there would not be any random failures.

#13 Updated by Markus Klein about 6 years ago

  • Status changed from New to Closed

Great!

Well, there should never be a situation where one might trigger two requests in parallel that modify the LocalConfiguration file.
Moreover locking at this low level is really tough and generally there is no clean locking mechanism for PHP that works everywhere.

So my answer is, No.

Also available in: Atom PDF