Bug #48882
closed
Added by Chili no-lastname-given over 11 years ago.
Updated almost 11 years ago.
Description
Whenever I use the clear-all-caches-Button my error log fills-up with this warning:
Core: Error handler (BE): PHP Warning: in_array() expects parameter 2 to be array, null given in (...)/typo3_src/typo3_src-4.7.12/t3lib/class.t3lib_iconworks.php line 619
and
Core: Error handler (BE): PHP Warning: include_once(/(...)/typo3temp/sprites/e61b6dcdaa95dde426d6eea161b95c55.inc): failed to open stream: No such file or directory in /(...)/typo3_src/typo3_src-4.7.12/t3lib/class.t3lib_spritemanager.php line 152
First I thought the spritemanager-problem is caused by wrong permissions, but the sprites-folder has 777 (just to find out if it is a permission-issue) but I get the warnings anyway.
Cannot confirm this on the current master (6.2-dev).
Does the file e61b6dcdaa95dde426d6eea161b95c55.inc actually exist in this folder?
The file was missing! There is another .inc file in this folder. I tried to find out where the missing file has gone and I found it in my backup, which I made before the TYPO3-update.
I copied it into the sprites-folder and everything seems to be fine right now. But I still ask myself why TYPO does not use the new .inc file? The old one was deleted when I used the cleaning-option of the install tool. I thought that this would be the best and safest way to do so but when I clean the sprites folder again to test what happens, the .inc is deleted, after clearing the cache a new .inc is generated AND the log is again full of the warnings because the old .inc is not there anymore. Is this designed to be like this?
I forgot to mention that we use a NFS cluster for our TYPO3, so the typo3temp-folder is shared. I checked the permissions in the fstab and they are okay, too (otherwise the apache couldn't write anything in the typo3temp folder, but it does; e.g. it builds a new .inc ).
- Status changed from New to Needs Feedback
The name of the file depends on:
- PATH_site
- $GLOBALS['TBE_STYLES']['spritemanager']
- $GLOBALS['TBE_STYLES']['spriteIconApi']['coreSpriteImageNames']
- $GLOBALS['TYPO3_CONF_VARS']['EXT']['extList']
You mention that the file system is shared between multiple instances. Are the items mentioned above equal for all the sites that use the shared file system? If that is true they share the same sprite cache file.
In the function that loads the sprite file there is a check to see if the file exists before including it. Theoretically it could be possible that one of the other instances removes the cache files it doesn't need (it doesn't know the name of its own previous file because the extension list might be changed) between the check and the actual include.
Furthermore you mention an NFS share that's used. I've once seen such behaviour and the sysadmin noticed in that situation that the NFS share would sometimes simply disappear for a short while. He could find error messages that indicate that the NFS simply wasn't available after the initial check that the file existed. Maybe you can investigate if that is the case here?
Jigal van Hemert wrote:
The name of the file depends on:
- PATH_site
- $GLOBALS['TBE_STYLES']['spritemanager']
- $GLOBALS['TBE_STYLES']['spriteIconApi']['coreSpriteImageNames']
- $GLOBALS['TYPO3_CONF_VARS']['EXT']['extList']
You mention that the file system is shared between multiple instances. Are the items mentioned above equal for all the sites that use the shared file system? If that is true they share the same sprite cache file.
In the function that loads the sprite file there is a check to see if the file exists before including it. Theoretically it could be possible that one of the other instances removes the cache files it doesn't need (it doesn't know the name of its own previous file because the extension list might be changed) between the check and the actual include.
Furthermore you mention an NFS share that's used. I've once seen such behaviour and the sysadmin noticed in that situation that the NFS share would sometimes simply disappear for a short while. He could find error messages that indicate that the NFS simply wasn't available after the initial check that the file existed. Maybe you can investigate if that is the case here?
The items above are equal and, yes, they share the same sprite cache file.
Do you mean that when I delete the sprite cache on one instance_01 and click on clear cache just some seconds later, the second instance_02 has build a new .inc, the ckeck does not include a new one, because there is one already, and nevertheless both instances miss the old.inc? Is there a chance to check this process?
I also had a look on the NFS and I can say that's everything fine with is it.
Okay, I get the same problem when I e.g. try to install an extension. In my case I installed the image cycle extension. First I did that on the second node, then on the first. Afterwards my log was again full of these warnings. I didn't make a backup of the tempfolder before installation, so I had no old .inc file to copy. With cp I copied the existing file and renamed it to the one typo3 was searching for - my log is fine now and all the icons are there again.
This can't be the workaround for this issue...isn't there a way to programm something like 'if a .inc is missing just take the old/existing one?'
Hi,
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.1)?
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this ticket.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.
Also available in: Atom
PDF