This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: apache dies with pppoe

Brian Dessent wrote:
> I'm in agreement here, Apache should not give two shits what your
> external IP address is if it's behind a NAT gateway and is bound to an
> interface with a non-changing address.  In fact it has no possible way
> of knowing what the publicly-visible address is.

I agree as well. However, the fact remains that Apache will run and run
until I open up the HTTP port on my FW. After the port is open it runs for
some time and then (speaking TCP/IP sockets here) it either stops listening
for client connections or stops accepting client connections. At least
that's what it looks like based on my experience writing more than a few
client/server programs. It's likely more complicated than that though.

> If Apache is dying after a certain time then that's obviously a problem,
> and I'd suggest checking the error logs and even increasing the
> loglevel, but the changing IP address shouldn't have anything to do with
> it.  I have found cases myself where Apache stops responding, but I've
> not been able to figure it out so I do have some interest in this
> matter.

It will some times stop even with no outside connections (from the WAN)
having been made (based on /var/log/appache/access_log). At least on one
occasion, I opened up the port just for testing this issue, then continued
making connections via the LAN side and then inexplicably Apache quits
without anything being written to /var/log/appache/error_log. Increasing the
debug level is a worthwhile suggestion. Now, it doesn't quit/die; httpd and
parent and children still show up in the process list.

Andrew DeFaria recently replied to one of my posts (to me only) with this:

	I do know that Apache for Cygwin used to have a problem where it would lock
up, which is one 	of the reasons I'm using Apache for Windows (The other is
that Apache for Cygwin is slow - 	but it does understand things like
symlinks...). I narrowed it down to when it locked up I 	would selectively
kill a couple of the httpd's and wham it would start working again. I
believe the very newest versions of Cygwin and Apache for Cygwin fixed this
problem I think.

There's another piece of information that might be worth mentioning here,
however off-topic it may seem. That is Code-Red. When I open port 80, my
Netgear FVS318 starts logging a good amount (they arrive in 6's) of Code-Red
activity. This is the Code-Red virus scanning my IP, finding port 80 open,
and trying to get in. Based one the message from my router ...

	Thur, 07/24/2003 15:34:57 - TCP connection dropped - Source:,
2278, WAN - 	Destination:, 80, LAN - 'Code-Red'
	End of Log ----------

... it appears to be unsuccessful. AVG anti-virus says my system is clean
too. Maybe there's a connection here, maybe not.

Something else I've seen in the access log (although not consistently) are
the inevitable people that try to hack in like this: - - [24/Jul/2003:21:07:08 -0500] "GET /scripts/..%255c..%
pts\script.exe 	HTTP/1.1" 404 316

Again, this is not consistent; I've had Apache quit (responding) without
seeing this, so if this does send Apache into a tizzy, there's more than one
cause to this problem.

I've done some more testing (just today in fact,) and now have evidence that
would be contrary to my own damn "PPPOE/DHCP/new IP" argument. After an
'apachectl restart' I noted my WAN IP. When Apache stopped responding some
time later (about an hour as near as I can tell,) my WAN IP was still the
same. I don't think it's likely that I would get the same IP after a

I'm going to try some other basic test's here:

	1. httpd running with no other CYGwin process'
	2. httpd running with no other CYGwin process' and no Win32 MySQL
		(I've got perl code that makes MySQL connections)
	3. httpd running, no windows user logged in

I'll take any other suggestions as well.


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]