3

I've read several threads about this, but still can't resolve the issue.

We use apache + PHP-FPM. In Magento tree files are owned by apache-user:dev. Now, using 775 / 664 for dirs and files. Also, we disabled redis and using files for backend cache.

When I clear / flush cache in backend, most files get written in magento-dir/var/cache as usual, but I noticed some files are written in system /tmp (not in /tmp/magento). Actually, 14 files with "Locale" serialized data:

zend_cache---internal-metadatas...

zend_cache---Zend_LocaleC...

zend_cache---Zend_LocaleL...

That is, some files get written correctly in var/cache and others in system /tmp directory.

Running scripts in magento root to get system var dir:

<?php
echo sys_get_temp_dir();
?>

returns /tmp

and magento var:

<?php 

require_once('app/Mage.php'); //Path to Magento
umask(0);
Mage::app();

$var_dir = Mage::getModel('core/config')->getVarDir(); 
echo $var_dir;

Returns magento-dir/var, as expected.

Also, permissions seem correct, since most files get written properly.

Anyone with this behavior?

3 Answers 3

1

It happens when you do not have writing permissions on var folder. Make sure you can read and write it.

3
  • Thanks @RiccardoT I tried all combinations I could think of, even chown -R www-data:www-data magento-folder/ and chmod -R 777 magento-folder... and still. Any ideas?
    – Marc
    Mar 4, 2016 at 19:29
  • @Marc Had this issue some does ago on a shared hosting, where the customer has his hosting, as he don't want dedicated source. The way you told above to override File.php was the only way to get it working too. Still havent figured out why. I got warned by n98-magerun that he tries to write to /tmp/var/magento/ instead of <mageroot>/var/. After i rm'd the /tmp dirs it first looked like it's working but out of sudden it 'returned' to /tmp. I don't like the idea about overriding something like Zend Cache in local. So if you find an answer, please share it.
    – Michael
    Mar 6, 2016 at 20:42
  • @Michael I also noticed thanks to n98 and it's helpful warnings! I don't like overriding files neither... I launched a fresh LAMP Ubuntu box with a CE 1.9.2.4 and those cache files where written in system's /tmp. Couldn't figure out why, since most cache files get properly populated in /magento/var/cache. I'll try to dig into it - when I have time ;) I would appreciate someone giving a proper answer.
    – Marc
    Mar 6, 2016 at 21:28
1

This is the only option that worked for me:

Copy contents from

lib/Zend/Cache/Backend/File.php

To

app/code/local/Zend/Cache/Backend/File.php

And editing line :99

Instead of 'cache_dir' => null, 'cache_dir' => 'var/cache',

as in

protected $_options = array(
        'cache_dir' => 'var/cache',
        'file_locking' => true,
        'read_control' => true,
        'read_control_type' => 'crc32',
        'hashed_directory_level' => 0,
        'hashed_directory_perm' => 0700,
        'file_name_prefix' => 'zend_cache',
        'cache_file_perm' => 0600,
        'metadatas_array_max_size' => 100
    );
1
  • I also encountered this weird problem. There is a class named Mage_Cache_Backend_File that override the Zend_Cache_Backend_File, so we shouldn't have those file written in /tmp with the prefix mage instead zend_cache, because of line 78 'file_name_prefix' => 'mage'? Feb 3, 2017 at 8:56
1

It was designed to work that way. Zend cache will be stored in /tmp. Have to dig deep to identify the reason for not having inside var/cache. But my safe guess would be those are the core Zend files which will not be touched by making changes via admin. Because /tmp is the folder which cache wsdl's as well when your application uses soap api integration.

1
  • Thanks @Senthil, agreed. If permissions aren't setup correctly and the application can't write to its /var/cache, then systems /tmp is used and cache files are created under /tmp/magento/..., however looks like Zend cache files will be always stored in /tmp per design. Might this be an issue running multiple stores in same server?
    – Marc
    Mar 7, 2016 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.