<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.apache.user">
    <title>gmane.comp.apache.user</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99960"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99959"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99958"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99957"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99956"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99955"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99954"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99953"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99952"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99951"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99950"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99949"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99948"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99947"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99946"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99945"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99944"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99943"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99942"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.apache.user/99941"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99960">
    <title>Re: LD_LIBRARY_PATH issue in 2.2.22 and earlier</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99960</link>
    <description>&lt;pre&gt;I think this memo is really directed to me and the comment about PHP 5.4.0 
not working with Apache 2.4.1 and 2.4.2.  

If so, what happened (documented in a closed request to this list) was that 
I compiled both these Apache versions in late March against PHP 5.4.0 which 
was the latest version at the time.  Haven't looked since.  Apache worked 
fine but the PHP scripts were displayed in raw form on the client instead of 
the expected result.  These are scripts that have been working properly for 
years.  I finally discovered from the Apache error log that whenever a PHP  
script was processed one of the child processes segfaulted.  I wrote up a 
request to this forum and someone was able to confirm it was a PHP problem 
so I reported it to their help but was unable to figure out how to get the 
documentation that was required (traces and so forth) so the report was 
closed.

What happened beyond that I can't say.   Hope that is useful.

Regards,

John

&lt;/pre&gt;</description>
    <dc:creator>John Iliffe</dc:creator>
    <dc:date>2012-05-25T14:53:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99959">
    <title>Re: Error: The page isn't redirecting properly</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99959</link>
    <description>&lt;pre&gt;Hi Frank,

Frank Gingras &amp;lt;francois.gingras&amp;lt; at &amp;gt;gmail.com&amp;gt; writes:

[snip]



[snip]


I haven't any RewriteRule / Redirect / RedirectMatch directives in my
apache2 config files.

I disabled even the rewrite apache2 module.

&lt;/pre&gt;</description>
    <dc:creator>Csanyi Pal</dc:creator>
    <dc:date>2012-05-25T14:12:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99958">
    <title>Re: Solved  non-www to www redirect works with a little issue</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99958</link>
    <description>&lt;pre&gt;
Solved :-)

RewriteRule ^(.*) http://www.example.com/%{REQUEST_URI} [R=301]


On Fri, 25 May 2012 16:23:29 +0530
"J. Bakshi" &amp;lt;joydeep&amp;lt; at &amp;gt;infoservices.in&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>J. Bakshi</dc:creator>
    <dc:date>2012-05-25T11:50:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99957">
    <title>non-www to www redirect works with a little issue</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99957</link>
    <description>&lt;pre&gt;Hello,

I have place the following in my .htaccess to redirect non-www to www redirection 

`````````````
RewriteCond %{HTTP_HOST} ^example\.com$
RewriteRule ^(.*) http://www.example.com/$1 [R=301]

```````````````

The redirect work well but a little hitch.
Say If I visit http://example.com/page1.html it redirect to
http://www.example.com so at the home page. Where it should
append the www before the link, but not alter the link.

What modification should I add here to make it work ?

Thanks
&lt;/pre&gt;</description>
    <dc:creator>J. Bakshi</dc:creator>
    <dc:date>2012-05-25T10:53:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99956">
    <title>Re: LD_LIBRARY_PATH issue in 2.2.22 and earlier</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99956</link>
    <description>&lt;pre&gt;John Iliffe schrieb:




That's a little bit unclear.
In their release announcement they said it is fixed
"Fixed bug #61172 (Add Apache 2.4 support)."
&amp;lt;http://www.php.net/archive/2012.php#id2012-04-26-1&amp;gt;

But in the changelog #61172 is only listed for 5.3.11,
but not for 5.4.1.

   Hendrik
&lt;/pre&gt;</description>
    <dc:creator>Hendrik Schmieder</dc:creator>
    <dc:date>2012-05-25T07:05:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99955">
    <title>Re: Re: Error: The page isn't redirecting properly</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99955</link>
    <description>&lt;pre&gt;

On 24/05/12 08:37 PM, Mohamed Daif wrote:

That's a rather bad idea, and I advise against it.

Instead, look for RewriteRule / Redirect / RedirectMatch directives in 
your config files.


Frank
&lt;/pre&gt;</description>
    <dc:creator>Frank Gingras</dc:creator>
    <dc:date>2012-05-25T02:30:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99954">
    <title>Re: CLOSE_WAIT problem</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99954</link>
    <description>&lt;pre&gt;Hi Igor,

Right. Maybe I can eliminate them as os params.

But, I agree the following contents("It is not a TCP tuning issue") about
CLOSE_WAIT.

http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html

But, thank you again for your information!

Thanks.

Regards,
Bongjae Chang

From:  Igor Cicimov &amp;lt;icicimov&amp;lt; at &amp;gt;gmail.com&amp;gt;
Reply-To:  &amp;lt;users&amp;lt; at &amp;gt;httpd.apache.org&amp;gt;
Date:  Friday, May 25, 2012 7:32 AM
To:  &amp;lt;users&amp;lt; at &amp;gt;httpd.apache.org&amp;gt;
Subject:  Re: [users&amp;lt; at &amp;gt;httpd] CLOSE_WAIT problem


You can reduce the time on OS level if you want by tuning the tcp stack.
On May 25, 2012 3:00 AM, "Bongjae Chang" &amp;lt;bongjae.chang&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


&lt;/pre&gt;</description>
    <dc:creator>Bongjae Chang</dc:creator>
    <dc:date>2012-05-25T02:01:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99953">
    <title>Re: Re: Error: The page isn't redirecting properly</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99953</link>
    <description>&lt;pre&gt;hi

try this command

chmod -R 777 /var/www/"joomla-location"/



On Thu, May 24, 2012 at 2:53 PM, Csanyi Pal &amp;lt;csanyipal&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Mohamed Daif</dc:creator>
    <dc:date>2012-05-25T00:37:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99952">
    <title>Re: CLOSE_WAIT problem</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99952</link>
    <description>&lt;pre&gt;You can reduce the time on OS level if you want by tuning the tcp stack.
 On May 25, 2012 3:00 AM, "Bongjae Chang" &amp;lt;bongjae.chang&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Igor Cicimov</dc:creator>
    <dc:date>2012-05-24T22:32:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99951">
    <title>Re: LD_LIBRARY_PATH issue in 2.2.22 and earlier</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99951</link>
    <description>&lt;pre&gt;
Modify your installed envvars (and envvars-std) script and apachectl (or equivilant
script provided by your application vendor) to ensure that this code is changed;


&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -18,6 +18,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #
 # This file is generated from envvars-std.in
 #
-LD_LIBRARY_PATH="/path/to/httpd/lib:$LD_LIBRARY_PATH"
+if test "x$LD_LIBRARY_PATH" != "x" ; then
+  LD_LIBRARY_PATH="/path/to/httpd/lib:$LD_LIBRARY_PATH"
+else
+  LD_LIBRARY_PATH="/path/to/httpd/lib"
+fi
 export LD_LIBRARY_PATH
 #

On oddball platforms this may be LIBPATH or SHLIB_PATH instead of LD_LIBRARY_PATH.
If your platform's apachectl script invokes envvars, you are done.  If it doesn't,
there may be an insecure LD_LIBRARY_PATH assignment, just use the example above.

Upgrading for this defect is frankly silly, although effective.  There is no planned
date yet for 2.2.23 although it will come along sometime in the not too distant
future.
&lt;/pre&gt;</description>
    <dc:creator>William A. Rowe Jr.</dc:creator>
    <dc:date>2012-05-24T19:30:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99950">
    <title>Should name based virtual hosts work when the ServerName is an IP address?</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99950</link>
    <description>&lt;pre&gt;If I have a configuration like this:

NameVirtualHost 192.200.0.1:80
&amp;lt;VirtualHost 192.200.0.1:80&amp;gt;
        ServerName default.example.com
... stuff ...
&amp;lt;/VirtualHost&amp;gt;
&amp;lt;VirtualHost 192.200.0.1:80&amp;gt;
        ServerName a.example.com
... stuff ...
&amp;lt;/VirtualHost&amp;gt;

then http://a.example.com/ will return the second site (correctly), not the
default site.

If I use an IP address as the name of the second site like this:

NameVirtualHost 192.200.0.1:80
&amp;lt;VirtualHost 192.200.0.1:80&amp;gt;
        ServerName default.example.com
... stuff ...
&amp;lt;/VirtualHost&amp;gt;
&amp;lt;VirtualHost 192.200.0.1:80&amp;gt;
        ServerName 192.200.0.1
... stuff ...
&amp;lt;/VirtualHost&amp;gt;

the I would expect http://192.200.0.1/ to return the second site, not
the default site. However, it seems to return the default.

Is this a bug, and is there any work around? (I want the default site
to be there still).

&lt;/pre&gt;</description>
    <dc:creator>Alex Bligh</dc:creator>
    <dc:date>2012-05-24T19:13:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99949">
    <title>Turning mod_reqtimeout off on a per session basis</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99949</link>
    <description>&lt;pre&gt;I am seeing some odd behaviour with mod_reqtimeout, and have a couple
of questions on its internals (apache2-mpm-prefork 2.2.14-5ubuntu8.9)

Q1. I have an environment which is doing this (in essence):

RequestReadTimeout header=10-20,minrate=500
RequestReadTimeout body=10,minrate=500

NameVirtualHost 192.200.0.1:80
... uninteresting default virtual host...
&amp;lt;VirtualHost 192.200.0.1:80&amp;gt;
        ServerName a.example.com
RequestReadTimeout header=0 body=0
... stuff ...
&amp;lt;/VirtualHost&amp;gt;

RequestReadTimeout on the VirtualHost does not override RequestReadTimeout
at a global level. I still see mod_reqtimeout closing the socket to
long lasting requests on this virtual host. Disabling at the global
level works fine. Have I misunderstood how this is meant to work?

Q2. Sadly, disabling it at the global level isn't really enough for me.
What I am doing is using self.disconnect's apache modwebsockets code.
The sessions it uses are long lasting. Running without SSL (we seem
to have fewer problems with SSL) we see disconne&lt;/pre&gt;</description>
    <dc:creator>Alex Bligh</dc:creator>
    <dc:date>2012-05-24T18:13:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99948">
    <title>Re: LD_LIBRARY_PATH issue in 2.2.22 and earlier</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99948</link>
    <description>&lt;pre&gt;
The actual text is, "envvars (aka envvars-std) in the Apache HTTP Server 
before 2.4.2 places a zero-length directory name in the LD_LIBRARY_PATH, 
which allows local users to gain privileges via a Trojan horse DSO in 
the current working directory during execution of apachectl."

And envvars-std (envvars) appears to only be used by apachectl.  So, 
instead of upgrading, what about changing the owner of apachectl to root 
and the permissions to 700?  Then tell your auditor that you have 
implemented a compensating control for CVE-2012-0883 such that apachectl 
can only be run by the trusted root user.

Am I misunderstanding the vulnerability?

Or, alternatively, edit /usr/sbin/envvars and/or apachectl to fix 
LD_LIBRARY_PATH, if it is in fact being handled insecurely on your 
system (it appeared to be fine on the two older systems where I checked 
for this vulnerability).


--
   Mark Montague
   mark&amp;lt; at &amp;gt;catseye.org
&lt;/pre&gt;</description>
    <dc:creator>Mark Montague</dc:creator>
    <dc:date>2012-05-24T18:12:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99947">
    <title>Re: Denial of Service due to multiplication of httpd running</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99947</link>
    <description>&lt;pre&gt;

Thanks. As I said that problem raised its head because there were 160 of them
and the system was swapping itself to death. But that was on an earlier
version (2.2.0 I think it was). I will look at MaxSpareServers.


OK, my MaxSpareServers is 20 and I had 21 (mind you that is counting the
master, so maybe it was actually 20) yesterday all day.



&lt;/pre&gt;</description>
    <dc:creator>Bill Unruh</dc:creator>
    <dc:date>2012-05-24T17:58:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99946">
    <title>Re: LD_LIBRARY_PATH issue in 2.2.22 and earlier</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99946</link>
    <description>&lt;pre&gt;The upgrade to 2.4.2 is non-trivial in my environment (particularly due to the config changes) and if 2.2.23 is going to patch it, I'd just as soon wait. Thus the request for some guess at release date.

But that's likely not forthcoming, so I'll reconsider the upgrade.

---

Bibliopolis, LLC
Berkeley | Pittsburgh

http://www.bibliopolis.com




On May 24, 2012, at 1:17 PM, John Iliffe wrote:


&lt;/pre&gt;</description>
    <dc:creator>Luke Lozier</dc:creator>
    <dc:date>2012-05-24T17:22:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99945">
    <title>Re: LD_LIBRARY_PATH issue in 2.2.22 and earlier</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99945</link>
    <description>&lt;pre&gt;I got caught the same way in March (re PCI scanning).  Guess my guy is more 
up to date than yours!

There should be no reason that I found not to update to 2.4.2 BUT BE 
CAREFUL OF THE CONFIG FILE CHANGES!  For example the "order deny allow" 
format directives no longer work in 2.4.*.  There are a few other changes.

Also, do not be tempted to update to PHP 5.4.0 as it will cause segfaults 
in all the child processes for reasons that escape me completely.  Use a 
5.3.x version.  This may be my problem but someone on this list was able to 
confirm the issue and said that it is a PHP issue.  It may be resolved by 
now.

Hope that's useful.

John
======================================
On Thursday 24 May 2012 13:05:10 Luke Lozier wrote:
&lt;/pre&gt;</description>
    <dc:creator>John Iliffe</dc:creator>
    <dc:date>2012-05-24T17:17:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99944">
    <title>LD_LIBRARY_PATH issue in 2.2.22 and earlier</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99944</link>
    <description>&lt;pre&gt;One of the PCI scanning companies is demanding an upgrade to 2.4.2 due to the issues described in this CVE:
Changes with Apache 2.2.23

  *) SECURITY: CVE-2012-0883 (cve.mitre.org)
     envvars: Fix insecure handling of LD_LIBRARY_PATH that could lead to the
     current working directory to be searched for DSOs. [Stefan Fritsch]
Is there any idea when 2.2.23 will be released? I'd rather not upgrade to 2.4.2

Apologies if this is the wrong list for this.

Best,

Luke Lozier

---

Bibliopolis, LLC
Berkeley | Pittsburgh

http://www.bibliopolis.com




&lt;/pre&gt;</description>
    <dc:creator>Luke Lozier</dc:creator>
    <dc:date>2012-05-24T17:05:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99943">
    <title>RE: Proxy streaming of files</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99943</link>
    <description>&lt;pre&gt;Does anybody have any experience with files streaming?


From: Salvador, Edwin [mailto:esalvador&amp;lt; at &amp;gt;intercall.com]
Sent: Tuesday, May 22, 2012 12:33 PM
To: 'users&amp;lt; at &amp;gt;httpd.apache.org'
Subject: [users&amp;lt; at &amp;gt;httpd] Proxy streaming of files

I configured a reverse-proxy server using apache, but I need to know if the files can be streamed to the requestors while they are being transferred from the proxied server and stored in the cache.
Can streaming work with any type of file, no matter if it's a plain text, html or picture?

Any help is highly appreciated.

Thank you
&lt;/pre&gt;</description>
    <dc:creator>Salvador, Edwin</dc:creator>
    <dc:date>2012-05-24T17:03:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99942">
    <title>Re: Denial of Service due to multiplication of httpd running</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99942</link>
    <description>&lt;pre&gt;A dozen or so idle processes is perfectly normal for prefork (which
you are clearly running, BTW). Only worry about this if there are a
consistently high number of idle processes (say 30 or more for a lightly
loaded server) in which case you can tune the value of MaxSpareServers
to suit.

Have a read about the prefork MPM in the documentation:
http://httpd.apache.org/docs/2.2/mod/prefork.html

If the number of idle processes is consistently higher than
MaxSpareServers you have a bug.

HTH,

Pete
&lt;/pre&gt;</description>
    <dc:creator>Pete Houston</dc:creator>
    <dc:date>2012-05-24T17:02:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99941">
    <title>Re: CLOSE_WAIT problem</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99941</link>
    <description>&lt;pre&gt;Hi Eric,
Thank you for quick reply.

You mean if Apache picks up the closed conn and tries to do some I/O
operations like writing, Apache will failover the conn(with closing the
conn and creating/reusing new conn). So CLOSE_WAIT may be normal in this
case, right?

IMHO, as soon as connections are closed from backend, if Apache can detect
closed connections of backend and close them explicitly, CLOSE_WAITs can
disappear as soon as possible before Apache tries to reuse them.

Honestly, I didn't know the CLOSE_WAIT conn would be able to be reused
because new connections always established in my test(I shut down the old
backend and rebooted the new backend, then both ESTABLISHED and CLOSE_WAIT
existed).

And I read the default max number which will be allowed to backend is
ThreadsPerChild directive and users can set the max or ThreadsPerChild to
be a big number. Then, I think many CLOSE_WAITs can be piled up. It's a
waste of FDs.

Actually, I was afraid of the following situation.

1. Apache has many backend con&lt;/pre&gt;</description>
    <dc:creator>Bongjae Chang</dc:creator>
    <dc:date>2012-05-24T16:59:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.apache.user/99940">
    <title>Re: Denial of Service due to multiplication of httpd running</title>
    <link>http://permalink.gmane.org/gmane.comp.apache.user/99940</link>
    <description>&lt;pre&gt;I was too quick to cry ignorance. I have now gotten mod_status working and
here is the output. For some bizarre reason the number of servers is
multiplying

68.58.140.236 was downloading another page with lots of pictures on it.
(http://axion.physics.ubc.ca/titanic/-- axion is an ancient pseudonym for
www.theory.physics.ubc.ca)

Why are these idle servers multiplying? As I said this all started out by my
having 160 of them which was causing swapping death for the system.

How do I tell apache not to do this multiplication of servers?

Note that the aggregator requests keep coming even though the virtual host
which hosted them is disconnected (commented out in the httpd configuratio
nfiles)



-------------------------------------------------------------

Apache Server Status for www.theory.physics.ubc.ca

Server Version: Apache/2.2.22 (Mandriva Linux/PREFORK-0.1mdv2010.2)
mod_ssl/2.2.22 OpenSSL/1.0.0a PHP/5.3.13 with Suhosin-Patch mod_perl/2.0.4
Perl/v5.10.1
Server Built: Feb 1 2012 12:26:04

Current Time: T&lt;/pre&gt;</description>
    <dc:creator>Bill Unruh</dc:creator>
    <dc:date>2012-05-24T16:28:40</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.apache.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.apache.user</link>
  </textinput>
</rdf:RDF>

