Red Hat Bugzilla – Bug 71097
PHP leaves around a SYSV Semaphore.
Last modified: 2007-04-18 12:45:21 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606 Description of problem: Running PHP at the command line leaves a SYSV semaphore lying around. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. run ipcs and make a note of the sysv sem's 2. run 'php -v' 3. run ipcs and see the left over sem's Actual Results: usw-pr-shell1:~# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status ------ Semaphore Arrays -------- key semid owner perms nsems status ------ Message Queues -------- key msqid owner perms used-bytes messages usw-pr-shell1:~# php -v 4.1.2 usw-pr-shell1:~# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status ------ Semaphore Arrays -------- key semid owner perms nsems status 0x00000000 167968768 root 600 1 0x00000000 168001537 root 600 1 ------ Message Queues -------- key msqid owner perms used-bytes messages Expected Results: No left over semaphores. Additional info:
Ok lets see first off, is this in the latest for the upcoming release.... [root@dhcp59-202 root]# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status ------ Semaphore Arrays -------- key semid owner perms nsems status 0x00000000 327680 apache 600 1 0x00000000 360449 root 600 1 0x00000000 393218 apache 600 1 ------ Message Queues -------- key msqid owner perms used-bytes messages [root@dhcp59-202 root]# php -v 4.2.2 [root@dhcp59-202 root]# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status ------ Semaphore Arrays -------- key semid owner perms nsems status 0x00000000 327680 apache 600 1 0x00000000 360449 root 600 1 0x00000000 393218 apache 600 1 ------ Message Queues -------- key msqid owner perms used-bytes messages [root@dhcp59-202 root] Nope (This is with php-4.2.2-6 currently in rawhide) Ok lets have a look for a 7.3 box,... Ok got one,.. lets make sure I've got the right php on it,.. (4.2.1-7.3.3) [root@ZenIIIb root]# ipcs > l [root@ZenIIIb root]# php -v 4.1.2 [root@ZenIIIb root]# ipcs > ll [root@ZenIIIb root]# diff l ll 22a23,24 > 0x00000000 1245194 root 600 1 > 0x00000000 1277963 root 600 1 [root@ZenIIIb root]# php -v 4.1.2 [root@ZenIIIb root]# ipcs > lll [root@ZenIIIb root]# diff l lll 22a23,26 > 0x00000000 1245194 root 600 1 > 0x00000000 1277963 root 600 1 > 0x00000000 1310732 root 600 1 > 0x00000000 1343501 root 600 1 Umm,.. well thats a bummer, it just creates new unclosed ipc channels for each invocation. The errata has been approved so I can't stop it now. It'll be a while before there's a new errata released for this. Now then, On the bright side of things, this is only with php -v [root@ZenIIIb root]# php /var/www/html/index.html [root@ZenIIIb root]# ipcs > llll [root@ZenIIIb root]# diff lll llll [root@ZenIIIb root]# the ipc channels are not closed with -v but in other (normal) use php is fine. Phil =--=
Not completely true. Type php, then hit CTRL-C, they're left around also. There are also some other cases.. You'd be supprised at how fast a shell server full of users runs outta sem's ;)
DOh,.. and this is the first anyone has reported it,.. does no one use php anymore? Investigating (the semaphore problem that is 8) ) Phil =--=
I can't reproduce on RHL7.3 with php-4.1.2-7. Could this be a side effect of a bug in some other package? FWIW, I'm fully up to date on the erratas, and am running i686 glibc, openssl, and kernel-2.4.18-5 (uniprocessor).
[root@ZenIIIb root]# rpm -q kernel php kernel-2.4.9-31 php-4.1.2-7.3.3 Phil =--=
(7.3 server) [root@zenIIIa root]# rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' glibc openssl kernel php glibc-2.2.5-37.i386 openssl-0.9.6b-28.i386 kernel-2.4.18-4.i386 kernel-2.4.18-5.i586 php-4.1.2-7.i386 (problem persists) (7.3 server) [root@ZenIIIb root]# rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' glibc openssl kernel php glibc-2.2.5-37.i386 openssl-0.9.6b-28.i386 kernel-2.4.9-31.i586 php-4.1.2-7.3.3.i386 (problem persists) (7.2 laptop) [root@bomb root]# rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' glibc openssl kernel php glibc-2.2.4-27.i686 openssl-0.9.6b-24.i686 kernel-2.4.9-31.i686 kernel-2.4.9-34.i686 php-4.0.6-15.i386 (problem persists) Looks to be a really old problem
Ok lets see what happens [root@ZenIIIb php-4.1.2]# ipcs > l ; strace -f -o test ./build-cgi/php -v ; ipcs > ll ; diff l ll 4.1.2 26a27,28 > 0x00000000 1835022 root 600 1 > 0x00000000 1867791 root 600 1 ... 3835 geteuid32() = 0 3835 getpid() = 3835 3835 shmget(IPC_PRIVATE, 33554432, IPC_CREAT|0x180|0600) = 3375110 3835 shmat(3375110, 0, 0) = 0x40636000 3835 getuid32() = 0 3835 shmctl(3375110, 0x102 /* SHM_??? */, 0xbfffd900) = 0 3835 getuid32() = 0 3835 getgid32() = 0 3835 shmctl(3375110, 0x101 /* SHM_??? */, 0xbfffd900) = 0 3835 shmctl(3375110, IPC_RMID, 0) = 0 3835 semget(IPC_PRIVATE, 1, IPC_CREAT|IPC_EXCL|0x180|0600) = 1835022 3835 semctl(1835022, 0, SETVAL, 0xbfffc88c) = 0 3835 semget(IPC_PRIVATE, 1, IPC_CREAT|IPC_EXCL|0x180|0600) = 1867791 3835 semctl(1867791, 0, SETVAL, 0xbfffc88c) = 0 3835 getpid() = 3835 3835 semop(1835022, 0x401d35a4, 2) = 0 3835 semop(1835022, 0x401d35b0, 1) = 0 3835 brk(0x821b000) = 0x821b000 3835 setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0 3835 rt_sigaction(SIGPROF, {0x812a9f0, [PROF], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 3835 rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0 3835 brk(0x821c000) = 0x821c000 3835 brk(0x821d000) = 0x821d000 3835 brk(0x821e000) = 0x821e000 3835 time(NULL) = 1028923432 3835 getpid() = 3835 3835 getpid() = 3835 3835 write(1, "4.1.2\n", 6) = 6 3835 _exit(1) = ? Humm looks like it's one of the last things it ever does (creating the semaphores) Ok maybe this isn't going to be as horrible to fix as I thought it was going to be Phil =--=
Ok,.. the version print is from sapi/cgi/cgi_main.c:642 or thereabouts. I compared it with 4.2.2's cgi_main.c and theres no differance for this codepath. Investigating backwards,... Phil =--=
traced to somewhere in the sapi/cgi/cgi_main.c:462 region,.. but by force of habit I compiled this as -g -O2 so the debugging stepping order is slightly wrong... rebuilding,.. Phil =--=
Ok,.. so php runs off to start up it's internal extensions (main.c:934) This leads us down to php_startup_extensions() (main.c:773) where the fun really starts, because,.. it's all pointers to functions (those damned wacky kids). It's during this routine that the semaphores are created. After some countless (and boring) long steps through the startup sessions for the built in modules we arrive at ext/session/mod_mm.c:276 which kicks off the call to ext/session/mod_mm.c:213 where the semaphores are created (mm_create(0, path);) Hummm Ok I'm going to transplant 4.2.2 ext/session into 4.1.x and see if it magically resolves the issue Phil =--=
<mutter> I cannot find a connection between 4.1.2 and 4.2.2 that explains the differing ipc behavior. Their codepaths are identical (for all intents and purposes) I'm going to boot this one into the php bugtracking system, to see if they've come across it or not. Phil =--=
http://bugs.php.net/bug.php?id=18863 Phil =--=
[root@alpha root]# ipcs > l [root@alpha root]# rpm -q php php-4.1.2-7.2.4 [root@alpha root]# php -v 4.1.2 [root@alpha root]# ipcs > ll [root@alpha root]# diff l ll Fixed in current errata
*** Bug 70846 has been marked as a duplicate of this bug. ***
Using php-4.1.2-7.3.4 on rh7.3 I'm still having this problem: # httpd -T Ouch! ap_mm_create(1048576, "/var/run/httpd.mm.20693") failed Error: MM: mm:core: failed to acquire semaphore (No space left on device): OS: Identifier removed ipcs indicate php -v still leak semaphore here. We also use php in batch mode, so apache fail to restart every morning at logrotate. apache-1.3.23-14 mod_ssl-2.8.7-6 php-4.1.2-7.3.4 kernel 2.4.18-10smp (2 cpu) glibc-2.2.5-39 or apache-1.3.23-14 mod_ssl-2.8.7-6 php-4.2.2 (based on rawhide) kernel 2.4.18-5bigmem (2 cpu) glibc-2.2.5-39
/var/run/httpd.mm.20693 wouldn't happen to suggest that it came from apache would it as opposed to php. anyway [root@bryce2 /]# rpm -q apache php apache-1.3.23-15 php-4.1.2-7.3.5 [root@bryce2 /]# httpd -T Syntax OK [root@bryce2 /]# ipcs > before [root@bryce2 /]# php -v 4.1.2 [root@bryce2 /]# ipcs > after [root@bryce2 /]# diff before after [root@bryce2 /]# It's queued up in errata. Just have to wait till QA get a chance to poke through it before it goes out live Phil =--=
Yes that msg came form apache. This is after I use php in batch mode for a while ipcs -c -s showing 128+? lines. At this point restart apache or httpd -T or php -v all die... # php -v Content-type: text/html PHP Fatal error: Unable to start session mm module in Unknown on line 0 # /etc/init.d/httpd start Starting httpd: Ouch! ap_mm_create(1048576, "/var/run/httpd.mm.20865") failed Error: MM: mm:core: failed to acquire semaphore (No space left on device): OS: Identifier removed # httpd -T Ouch! ap_mm_create(1048576, "/var/run/httpd.mm.20867") failed Error: MM: mm:core: failed to acquire semaphore (No space left on device): OS: Identifier removed I'll wait for php-4.1.2-7.3.5 than. Thanks.
Leaving this open whilst an errata is still pending.
(closing this rather than the other bug as a duplicate since it was filed later) *** This bug has been marked as a duplicate of 61030 ***
I know this bug is closed but what can I do if I am suffering from this problem? Under fully patched 7.2 (except for the glibc which breaks mysql), when I run /etc/rc.d/init.d/httpd configtest It leaks 2 semaphore arrays. I have increased the limit in /proc/sys/kernel/sem but I would like to know the correct solution. Before I increased the limit I got the following errors/output: Ouch! ap_mm_create(1048576, "/var/run/httpd.mm.2293") failed Error: MM: mm:core: failed to acquire semaphore (No space left on device): OS: Identifier removed