Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#9095 - php-apc crash

Attached to Project: Arch Linux
Opened by Victor Museteanu (vik) - Friday, 04 January 2008, 22:04 GMT
Last edited by Pierre Schmitz (Pierre) - Saturday, 05 January 2008, 11:45 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture x86_64
Severity High
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

I Just upgraded a busy web server, including php (5.2.4-2 -> 5.2.5-2), php-apc (3.0.14-4 -> 3.0.16-1). After 10 to 20 minutes, the server (apache) no longer shows php files, just prompts for download. When this happens, in log appears a large block of lines like:

[apc-error] apc_sem_lock: semop(4128783) failed: Identifier removed

folowed by another one with:

[apc-error] apc_sem_lock: semop(4128783) failed: Invalid argument


Additional info:
pacman -Q | grep php
php 5.2.5-2
php-apc 3.0.16-1
php-fileinfo 1.0.4-3
php-suhosin 0.9.22-1

cat /etc/php/conf.d/apc.ini
extension=apc.so
apc.shm_size=128
apc.ttl = 10800
apc.localcache=1
apc.localcache.size=512
apc.include_once_override=1

All the relevant config files are the same (except obvious like path to php modules) as before the upgrade.
In the attached file mrtg shows the increase of sockets usage after the upgrade.
I disabled apc now. If any other information is needed I try my best to provide it.
   semsock.png (20.4 KiB)
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Saturday, 05 January 2008, 11:45 GMT
Reason for closing:  Fixed
Comment by Victor Museteanu (vik) - Friday, 04 January 2008, 23:17 GMT
The fix suggested at http://pecl.php.net/bugs/bug.php?id=5280&edit=1 seems to solve the problem for me. At least it is working for 35 minutes now... Now it's past 1:00 AM for me, I'm going to test it longer tomorrow.
Comment by Pierre Schmitz (Pierre) - Friday, 04 January 2008, 23:26 GMT
Strange, I have seen those errors with 3.0.15 and they are gone with 3.0.16. But it might be that it only occurs in some special situations. See http://pecl.php.net/bugs/bug.php?id=5280

However: I have recompiled APC to use Linux Futex locking instead of semaphores. Would be nice if you could test this package: http://users.archlinux.de/~pierre/packages/x86_64/php-apc-3.0.16-2-x86_64.pkg.tar.gz
Comment by Victor Museteanu (vik) - Saturday, 05 January 2008, 10:03 GMT
We are talking about same bug (5280) on pecl.php.net. The patch proposed by basant dot kukreja at sun dot com fixed the problem for me, the server ran more than 5 hours with no problems.
I recompiled the unpatched source with --enable-apc-futex instead of --enable-apc-sem and it is working for 35 min under lot more stress than tonight. I assume it is going to work ok since the semaphores code is not used, but I'm a little worried about this text from ./configure --help: "Enable linux futex based locks EXPERIMENTAL". I'd rather disable both experimenal futex and buggy sem if patching is not wanted.
Comment by Pierre Schmitz (Pierre) - Saturday, 05 January 2008, 10:57 GMT
OK, I did some research about this. Since 3.0.16 APC uses pthread mutex locking by default if it is available. Accoring to some benchmarks this should be faster than semaphore anyway and more stable than futex locking. In addition to this, it is not marked as "experimental".

I think php-apc-3.0.16-3 should fix your problem.
Comment by Victor Museteanu (vik) - Saturday, 05 January 2008, 11:37 GMT
Pthread mutex locking seems to work fine, indeed.

Thank you very much!

Loading...