TYPO3 Core

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.

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.

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.

[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?

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.

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

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.

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.

What is in your AdditionalConfiguration?

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');

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.

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.