Bug 71097 - PHP leaves around a SYSV Semaphore.
PHP leaves around a SYSV Semaphore.
Status: CLOSED DUPLICATE of bug 61030
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
7.3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Joe Orton
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-08 14:38 EDT by Uriah Welcome
Modified: 2007-04-18 12:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-09-26 05:10:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Uriah Welcome 2002-08-08 14:38:10 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:
Comment 1 Phil Copeland 2002-08-08 15:30:47 EDT
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
=--=
Comment 2 Uriah Welcome 2002-08-08 15:44:24 EDT
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 ;)
Comment 3 Phil Copeland 2002-08-08 15:50:08 EDT
DOh,.. and this is the first anyone has reported it,.. does no one use php anymore?

Investigating (the semaphore problem that is 8) )

Phil
=--=
Comment 4 Peter Bowen 2002-08-08 22:40:12 EDT
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).
Comment 5 Phil Copeland 2002-08-08 22:44:09 EDT
[root@ZenIIIb root]# rpm -q kernel php
kernel-2.4.9-31
php-4.1.2-7.3.3


Phil
=--=
Comment 6 Phil Copeland 2002-08-08 22:52:22 EDT
(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
Comment 7 Phil Copeland 2002-08-09 16:19:35 EDT
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
=--=
Comment 8 Phil Copeland 2002-08-09 16:47:43 EDT
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
=--=
Comment 9 Phil Copeland 2002-08-09 19:12:32 EDT
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
=--=
Comment 10 Phil Copeland 2002-08-10 01:32:59 EDT
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
=--=
Comment 11 Phil Copeland 2002-08-11 23:47:07 EDT
<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
=--=
Comment 12 Phil Copeland 2002-08-12 00:36:22 EDT
http://bugs.php.net/bug.php?id=18863

Phil
=--=
Comment 13 Phil Copeland 2002-08-30 15:23:14 EDT
[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
Comment 14 Phil Copeland 2002-08-30 15:26:20 EDT
*** Bug 70846 has been marked as a duplicate of this bug. ***
Comment 15 Need Real Name 2002-09-03 15:56:09 EDT
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

Comment 16 Phil Copeland 2002-09-03 16:41:46 EDT
/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
=--=
Comment 17 Need Real Name 2002-09-03 17:36:20 EDT
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.


Comment 18 Joe Orton 2002-09-26 05:10:00 EDT
Leaving this open whilst an errata is still pending.
Comment 19 Joe Orton 2002-09-26 05:29:50 EDT
(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 ***
Comment 20 John Newbigin 2002-10-14 01:26:47 EDT
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

Note You need to log in before you can comment on or make changes to this bug.