Any other caching than var/cache? / Flush Magento Cache works, rm -rf var/cache not

Question

We did an update on production but still a translation which was newly defined in a translate.csv file did not work.

After rm -rf var/cache it still was not shown. We verified that the folder is empty. /tmp/magento also did not exist. After refreshing the page var/cache got filled again - so it is in fact used.

We were able to make it work by Flush Magento Cache in the backend - how can this be? Where else might the translation be cached?

edit

We found this in the local.xml

 <cache>
 <backend>apc</backend>
 <prefix>APC_</prefix>
 </cache>

The question is why Magento still writes to the cache folder.

• Pronto: It looks like it only uses APC for the backend.

Answer 1

If you use Memcached or APC, the system doesn't put anything to var/cache.

• Alex: We do not knowingly use APC / memcached; how can we check it?
• Pronto: app/etc/local.xml has cache related block. another reason might be that Magento doesn't have enough permissions to write stuff into var/cache
• Alex: Looks like we do use APC - edited the question.
• Fiasco Labs: Go into the APC cache management page and flush the APC cache there if the Magento Admin cache management doesn't take care of it. Sometimes APC can get stuck as well.
• user4351: This is incorrect. If you configure only one backend, then Magento (or better Zend), will still use a "slow_backend" and defaults to file system. Additionally, Memcached key expiration has to be done in files, since Memcache doesn't support it. Details here: fabrizio-branca.de/…

Answer 2

If you want a reliable way to flush the cache from the command line, that uses Magento to do the work, use magerun. Details on why this wasn't working are in the comments. Additionally, APC may aggressively cache opcodes that it will make your head spin. Redis support is now in the Magento installation since 1.8, you may as well use it: No more dual backends and native key expiration.