Bug 78922

Summary: Fails to release SysV semaphores when run in "inetd" mode
Product: [Retired] Red Hat Linux Reporter: Andrew Pam <xanni>
Component: mod_sslAssignee: Joe Orton <jorton>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-03 16:21:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andrew Pam 2002-12-03 16:21:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i586; U;) Gecko/20020606

Description of problem:
When Apache+mod_ssl is run using the "ServerType inetd" configuration instead of
the default "ServerType standalone" setting, the SysV semaphores are not
released on exit causing all available semaphores provided by the Linux kernel
to be exhausted.  This in turn causes all further connections to the Apache
server to return no data with the following message in the error_log:

[error] mod_ssl: Cannot allocate shared memory: mm:core: failed to acquire
semaphore (No space left on device)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
0. For this test, ensure the httpd service is not running.
1. Create a copy of /etc/httpd/conf/httpd.conf under a new name and change the
"ServerType" setting from "standalone" to "inetd".  Also add the "SSLEngine on"
directive at the top level.
2. Create an xinetd configuration to run /usr/sbin/httpd on TCP port 443 with
the -f option specifying the new config file from step 1 above.  Be sure to add
any other necessary parameters such as -DHAVE_SSL.
3. Reload xinetd to start accepting connections.  Use a web client to repeatedly
access content on the test SSL server.
4. Monitor /proc/sysvipc/sem and note that semaphores created by the apache user
(uid 48 by default) are not released, and that eventually they will be exhausted
and new connections will fail as described above.

Actual Results:  Semaphores created by apache are not released, all semaphores
are exhausted and all further SSL connections fail returning no data.

Expected Results:  Semaphores should have been released on exit.

Additional info:

Given the nature of this bug and lack of information in the apache or mod_ssl
changelogs, it may exist in all current versions on all platforms.

Comment 1 Joe Orton 2002-12-03 16:30:35 UTC

*** This bug has been marked as a duplicate of 74543 ***