This is with Apache 1.3.11.

I'm running into the same problem with apache 1.3.33 and PHP 4.3.10.  Under load, the server stops responding and I get the following error:

[Fri Jul  8 11:28:01 2005] [apc-error] apc_fcntl_lock failed errno:4

I'm using siege to benchmark various accelerators, which is how I ran into this issue.  Here's the command I used to test APC:

$ siege -c15 -t1M -b -f urls.txt

Fifteen simultaneous requests for URLs contained in urls.txt for one minute, as fast as possible.  Kills APC+Apache every time.  eAccelerator works fine.

Yeah, I have seen it too.  It is something that was introduced in the latest big merge of PHP-5.1 support.  It wasn't happening before that.  There aren't that many things in the new code that also applies to PHP 4.x, so it shouldn't be too bad to narrow down.  I'll get to it this afternoon or tomorrow.

By the way, if someone could attach gdb to the process when it gets into this state and get me a backtrace, it would help a lot.  I'm not able to reproduce it right now.

We'll try to have a look at it on Monday.

[Mon Jul 18 15:13:16 2005] [apc-error] apc_fcntl_lock failed errno:4

I'm also seeing these in my logs.  This is Apache 1.3.33, with PHP 4.4 running on an AMD based system (CentOS 4.1)

I think I have tracked this one down.  I think it is due to the stat vs. stat64 discrepancy that happens if the Apache process you are loading apc.so into was compiled with LFS support.  Try grabbing the CVS version of APC and use the --with-apxs configure flag on it.  That tries to compile APC with the same flags Apache was compiled with.

I pulled it from CVS and configured with --with-apxs, the server seems to run a bit longer but these messages are still showing up in the logs and gets to the point that the server stops responding.  I'm also seeing a lot of seg faults.

Then please provide a backtrace

apache 2.0.54(prefork) php-5.0.4 APC-3.0.4 on Dual Pentium III
(apc compiled with --with-apxs --enable-debug)
core dumped. I cann't reproduce this crash on single cpu machine or Apache is started with -X option.
http://www.sysadminday.org.ru/apc-4769.1.backtrace
I cann't provide the valid 20 lines php code right now, but I hope this backtrace can be usefull.

Could you try adding --enable-apc-sem to your configure line and see if you can reproduce the problem with semaphore locking?

Could the folks who see this problem please add your OS, kernel version number, libc version, and gcc version to this bug report to see if we can spot a pattern?

Just happeneded here, [apc-error] apc_fcntl_lock failed errno:35.

At the time APC was very low on memory,with high fragmentation ~50%. While requests were hitting the server several of the accessed files were modified (not-atomatically).

GCC 3.4.1, Linux 2.6.10-SMP PHP 5.1.0-CVS/APC 3.0.5-dev 

After the error occured all pages became inaccessible, waiting for a lock to be released.

Ok, I have added some fcntl robustness stuff.  Could people who have seen this problem please grab the latest CVS and see if you can still break it?

Thanks. It seems to work with options: --enable-apc-sem and --with-apxs
PHP 5.0.4 tested.

I'm running PHP 5.0.4  from Fedora Core4 on  x86_64  Dual CPU box and   I'm able to repeatedly repeat this error in the log file which leads to stall or sometimes stall happens without this error at all.    

To repeat it I run stress test for my application which performs search random queries, 10 concurrent connections. 

The application uses cache a lot... each page generation may cause  50-100 cache lookups. 

I tried using both fcntl locks and --enable-apc-sem and I get deadlocks in the  same place for both of them.  

The effect however is a bit different - I have all httpd processes deadlocked - so all apache children are getting busy and box load falls to zero.

Here is sample backtrace:

(gdb)
#0  0x00002aaaabc2eb77 in semop () from /lib64/libc.so.6
#1  0x00002aaab132e8e8 in apc_sem_lock (semid=14188550) at /tmp/APC-3.0.8/apc_sem.c:121
#2  0x00002aaab1328c76 in apc_cache_user_find (cache=0x5555559a2000,
    strkey=0x555555b092f8 "a:2:{i:0;s:13:\"sphinx_search\";i:1;a:9:{i:0;s:6:\"malaga\";i:1;s:4:\"db01\";i:2;i:3312;i:3;i:0;i:4;i:20;i:5;i:0;i:6;a:2:{i:0;i:2;i:1;i:1;}i:7;a:0:{}i:8;i:3;}}", keylen=153, t=1128976730) at /tmp/APC-3.0.8/apc_cache.c:505
#3  0x00002aaab1328108 in zif_apc_fetch (ht=Variable "ht" is not available.
) at /tmp/APC-3.0.8/php_apc.c:488
#4  0x00002aaaafd13bdd in zend_do_fcall_common_helper () from /etc/httpd/modules/libphp5.so
#5  0x00002aaaafd238a9 in zend_do_fcall_handler () from /etc/httpd/modules/libphp5.so
#6  0x00002aaaafd11255 in execute () from /etc/httpd/modules/libphp5.so
#7  0x00002aaaafd135ef in zend_do_fcall_common_helper () from /etc/httpd/modules/libphp5.so
#8  0x00002aaaafd11255 in execute () from /etc/httpd/modules/libphp5.so
#9  0x00002aaaafd135ef in zend_do_fcall_common_helper () from /etc/httpd/modules/libphp5.so
#10 0x00002aaaafd11255 in execute () from /etc/httpd/modules/libphp5.so
#11 0x00002aaaafd135ef in zend_do_fcall_common_helper () from /etc/httpd/modules/libphp5.so
#12 0x00002aaaafd11255 in execute () from /etc/httpd/modules/libphp5.so
#13 0x00002aaaafd135ef in zend_do_fcall_common_helper () from /etc/httpd/modules/libphp5.so
#14 0x00002aaaafd11255 in execute () from /etc/httpd/modules/libphp5.so
#15 0x00002aaaafcf1fed in zend_execute_scripts () from /etc/httpd/modules/libphp5.so
#16 0x00002aaaafcbcf47 in php_execute_script () from /etc/httpd/modules/libphp5.so
#17 0x00002aaaafd2a596 in php_ap2_register_hook () from /etc/httpd/modules/libphp5.so
#18 0x0000555555571253 in ap_run_handler () from /usr/sbin/httpd
#19 0x00005555555715a7 in ap_invoke_handler () from /usr/sbin/httpd
#20 0x000055555556e981 in ap_process_request () from /usr/sbin/httpd
#21 0x000055555556a04f in _start () from /usr/sbin/httpd
#22 0x000055555557aa79 in ap_run_process_connection () from /usr/sbin/httpd
#23 0x000055555556f6fe in ap_graceful_stop_signalled () from /usr/sbin/httpd
#24 0x000055555556f939 in ap_graceful_stop_signalled () from /usr/sbin/httpd
#25 0x00005555555703a0 in ap_mpm_run () from /usr/sbin/httpd
#26 0x000055555557612d in main () from /usr/sbin/httpd
(gdb) bt full
#0  0x00002aaaabc2eb77 in semop () from /lib64/libc.so.6
No symbol table info available.
#1  0x00002aaab132e8e8 in apc_sem_lock (semid=14188550) at /tmp/APC-3.0.8/apc_sem.c:121
        op = {sem_num = 0, sem_op = -1, sem_flg = 4096}
#2  0x00002aaab1328c76 in apc_cache_user_find (cache=0x5555559a2000,
    strkey=0x555555b092f8 "a:2:{i:0;s:13:\"sphinx_search\";i:1;a:9:{i:0;s:6:\"malaga\";i:1;s:4:\"db01\";i:2;i:3312;i:3;i:0;i:4;i:20;i:5;i:0;i:6;a:2:{i:0;i:2;i:1;i:1;}i:7;a:0:{}i:8;i:3;}}", keylen=153, t=1128976730) at /tmp/APC-3.0.8/apc_cache.c:505
        slot = Variable "slot" is not available.

Encountered similar errors, but errno 35 with:

APC 3.0.8 (phpize && configure --enable-apc --enable-apc-mmap --with-apxs && make)
Apache 2.0.51 (httpd-2.0.51-2.9.2.legacy)
PHP 4.3.11 (php-4.3.11-1.fc2.3.legacy)
Linux 2.6.10 (kernel-smp-2.6.10-1.771_FC2)
Fedora Core2 (if you haven't noticed yet :)

apc.ini:
extension = apc.so
[apc]
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 128
apc.optimization = 0
apc.num_files_hint = 4000
apc.ttl = 14400
apc.gc_ttl = 3600
apc.filters = 
apc.mmap_file_mask = 


Found in error logs:

apc_fcntl_lock failed errno:35


Apache was still working, straight HTML pages would load, some PHP pages would load (possibly cached PHP pages?), but some PHP pages would not load.  The Apache server-status page was responsive, etc.  I was not using ANY user cache entries, only purely PHP caching.

I finall had to disable the module (apc.enabled = 0).

Could you try current CVS?  There are a lot of fixes in the code, some of which could have fixed this.

Hi all,

I found this old bug report. It seemed that the issue was fixed, but now I must report that it seems to reappear.

We run Apache 2.2.2 on x864_64 (Kernel 2.6.18, FC5) with PHP 5.1.6 and have a reproducible test case.

The sympoms are that Apache stalls one process at 100% and the server stops to respond.

After a while we get the apc_fcntl_lock failed in the error log.

Are there any known issues yet? The installed version of APC is 3.0.12p2.


Best regards,


Thomas

Closing this bug as it's pretty old, if you're still seeing this problem then please try with an alternative locking type and the latest release as it may have fixed some faults.  Please update ticket #13474 if you continue to have issues: http://pecl.php.net/bugs/bug.php?id=13474