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