WARNING: Latest EA update changes eaccelerator cache_dir to /tmp

[wizzy420]

Watch out, we started getting pages about low disk space in /tmp after the latest cPanel update.

Eaccelerator used to set the cache_dir to /var/cache/eaccelerator by default.

It is mentioned in the changelogs. But this is pretty major, for us just from 12 hours this directory has hit close to 1GB. It used to be fine in /var as we had this taken into account and /var had plenty of room for the eventual 3-5GB this directory would fill to.

Be careful you have a huge /tmp if you rebuild after this last update. I don't know why cPanel would make a switch like this or their motivation.

W

 

[jdlightsey]

The change was made to benefit from securetmp. The eaccelerator documentation suggests using /tmp/eaccelerator (and this is the default if you don't set the cache directory in php.ini).

When E-Accelerator starts up it creates several levels of nested directories with single hex digits as their names. These directories are all created with 777 permissions, but e-Accelerator doesn't create the base directory. This meant that if /tmp was wiped during a reboot we'd need to recreate /tmp/eaccelerator before Apache starts. To work around that we were installing e-Accelerator with the cache_dir set to /var/cache/eaccelerator and creating that directory at install time. Having directories with 777 permissions outside of /tmp is a bad idea though, so with the new release of e-accelerator we added a patch so it would create the base cache_dir and moved it back to the default /tmp/eaccelerator location.

AFAIK, e-Accelerator doesn't provide any way of limiting the size of the cache_dir though, so this is definitely a problem that needs to be addressed. You can manually create a working directory somewhere outside of /tmp and change the cache_dir line in your php.ini file to use it, but I'd be very interested if you have any suggestions that would:

(1) Not create world writable directories on partitions mounted without noexec
(2) Not fill up /tmp
(3) Work with both FastCGI and DSO (writable by user accounts and 'nobody')

It may be that we just have to abandon compatibility with FastCGI and create /var/cache/eaccelerator with 700 permissions owned by nobody.

 

[wizzy420]

It may be that we just have to abandon compatibility with FastCGI and create /var/cache/eaccelerator with 700 permissions owned by nobody.

I don't think that would be extremely popular

Thanks for the fast response with the reasoning behind the change!

 

[wizzy420]

Just an update, I checked a backup file to find how big the old /var/cache/e was. Around 3.8GB

So, unless lot's of people have 4+GB of free /tmp space, this might just pop up again as more and more people rebuild with the new EzApache.

I'll need to repartition my hard drives to go with the new method.

W