Bug #97731
closed
DependencyInjectionContainer issues with shared storage on High Available setup
Added by Jeroen van Rossum over 2 years ago.
Updated 5 months ago.
Description
Hi There,
For a few customers we run TYPO3 on a High Available setup with multiple webservers and a single database.
All the caches and static contents (fileadmin, uploads) are stored on a network share (NFS) that all webservers can access.
Some requests will cause the following 500 error:
FastCGI sent in stderr: "PHP message: PHP Fatal error: require_once(): Failed opening required '/mnt/nfs/web/myuser/shared/var/cache/code/di/DependencyInjectionContainer_5cbe220783b1147afc206ff59cc1318dad117973.php' (include_path='.:/usr/share/php') in /data/home/myuser/sites/myuser/builds/latest/public/typo3/sysext/core/Classes/Cache/Backend/SimpleFileBackend.php on line 362
We already store almost all caches in Redis, but somehow the "DependencyInjectionContainer" caches cannot be stored in Redis.
We have these issues on multiple different environments.
Related issues
1 (1 open — 0 closed)
Hi Jeroen,
did you find any solution for this? From time to time i get this error in multiserver deployments with a shared var directory for a v11 instance.
I could not yet move the var dir to the instances themselves, this caused other problems :/ Any hint on how to solve this would be very welcome!
In v11 the line that causes the error looks like this:
return file_exists($pathAndFilename) ? require_once $pathAndFilename : false;
I suspect that file_exists returns a result from the nfs cache, while require_once actually tries to read it and then fails. There may be different ways to tackle this:
a) tune your nfs settings to disable / reduce attribute caching which will very likely hurt performance
b) patch the ContainerBackend (which inherits from SimpleFileBackend) and flush the stat cache before the require_once / file_exists (or maybe mute the error, check if the class that is supposed to be in the require_once file actually exists, if not return false?)
c) disable sharing the var/cache dir
I went with option c, hope that it all works out. Flushing the system cache will not work afterwards!
- Status changed from New to Needs Feedback
with v11 one can warm up the caches (core + DI) during deployment. Best practice would be then to ship the DI cache with the artifact?
- Related to Bug #100123: Regular exceptions due to dependency injection (di) cache added
- Status changed from Needs Feedback to Closed
Closing this due to lack of feedback. "cache:warmup" was OK for me.
- ./bin/typo3 cache:warmup in a CI step
- Deploy the new code
- Switch symlinks
If you still have issues, please open a new ticket with some v12+ issues.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by