Enabling APC causes internal server error

php centos fastcgi

6,429

Do you have open_dir restrictions in effect? If this is on user account I would set APC's tmp directory relative to users home directory with proper permissions.

6,429

VicePrez

Updated on September 18, 2022

Comments

VicePrez over 1 year
After installing and enabling APC 3.1.9 (Alternate PHP Cache), using pecl, i ran into an internal server error. I checked my error logs, and this is what shows up.

Error Logs:
```
PHP Fatal error:  PHP Startup: apc_mmap: mkstemp on /tmp/apc.efdb4d failed: in Unknown on line 0
[Wed Jul 06 23:47:41 2011] [error] mod_fcgid: process /var/www/cgi-bin/cgi_wrapper/cgi_wrapper(22397) exit(communication error), get unexpected signal 11
```
Instead of adding the APC extension to my php.ini file, i created an apc.ini file in /etc/php.d/, here's my current APC configuration

apc.ini configuration:
```
; /etc/php.d/apc.ini

extension = apc.so

apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 128M
apc.optimization = 0
apc.num_files_hint = 4096
apc.ttl = 7200
apc.user_ttl = 7200
apc.gc_ttl = 0
apc.cache_by_default = 1
apc.filters = ""
apc.mmap_file_mask = "/tmp/apc.XXXXXX"
apc.slam_defense = 0
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 10M
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
;apc.rfc1867 = 0
;apc.rfc1867_prefix = "upload_"
;apc.rfc1867_name = "APC_UPLOAD_PROGRESS"
;apc.rfc1867_freq = 0
apc.localcache = 0
apc.localcache.size = 512
apc.coredump_unmap = 0
apc.stat_ctime = 0
```
Even after disabling APC, i ran into another error while trying to log in to Plesk CP:
```
ERROR: Zend_Db_Statement_Exception
SQLSTATE[HY000]: General error: 1 Can't create/write to file '/tmp/#sql_6d7_0.MYI' (Errcode: 13)
```
I fixed the above problem by restarting my container through Plesk's Power Panel. I think it had to with changing /tmp to exec using mount -o remount,exec /tmp to solve permission errors during the APC installation through pecl. After the installation was done, I returned /tmp back to noexec. The gist of these steps can be found here.

The first error still remains unsolved.

I'm Currently running on:
- CentOS 5.6
- PHP 5.3.5
- FastCGI
- Installed APC 3.1.9
I'm not sure how to solve this problem. Is it because im using the lastest version of APC? or the apc.ini config? Does it matter where i enabled the apc extension? i.e. /etc/php.ini versus /etc/php.d/apc.ini

How about FastCGI and APC compability issues?

Any help or advice would be greatly appreciated.
- cyberx86 almost 13 years
  
  There is no problem with your apc.ini file - I have the exact same setup (CentOS/PHP 5.3.6/FastCGI/APC 3.1.6) and your apc.ini file worked without issue. I might guess that you have a permissions problem on your /tmp directory - try setting it to 0777 to diagnose; if that fixes it, either change the mmap path or narrow down the permissions to something acceptable.
- VicePrez almost 13 years
  
  @cyberx86 Thanks a lot buddy. I ended up solving the problem using your advice. The problem was on multiple fronts. The apc.ini file was supplemented by w3 total cache's plugin in its ini folder. It was owned by my ftp user (it was cp-ed directly from there to /etc/php.d/), so i just changed it to root/root, and the /tmp folder had restrictive permissions, so i loosened it up a little bit. Answer the question, so i can give you credit. Thanks again.
- cyberx86 almost 13 years
  
  Give it to @Aleksey Korzun - he has essentially the same thing, just approached differently, and posted it before I did (which is why I didn't post mine as an answer - didn't seem right). Glad it worked out - thanks for thought.
- VicePrez almost 13 years
  
  for sure @cyberx86. by the way, whats considered a secure set of permissions for the /tmp folder, and what would be an alternative to it?
- cyberx86 almost 13 years
  
  Ideally if you can avoid execution permissions that is a good. Usually tmp is owned by root - and you will have other 'users' writing there - which means at least 0666 is common. Most linux distros have 0777 drwxrwxrwt (t=only user can delete). Make it as tight as possible - if you don't have any users writing to tmp, try a 0664 or even a 0644, but I don't think most things will work with those.
- VicePrez almost 13 years
  
  thanks @cyberx86. I'll look into it more and see what I can get away with. I cant believe how much of an impact opcode caching has on a website. Onload times are reduced 50-70%.
- cyberx86 almost 13 years
  
  Depending on the type of site, a disk cache can be even more effective - either generating and serving static pages, or using a caching proxy (e.g. nginx's proxy_cache or squid); you may also consider looking into memcached. (And of course, check out the apc.php file that shows which pages get the most caching, etc - potentially useful).
VicePrez almost 13 years

thanks for looking out. pretty much what @cyberx86 stated.
Aleksey Korzun almost 13 years

Damn it @cyberx86! :)