Apache on the Netwinder

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

I am still struggling with reliability on the Netwinder.  I am hoping the
new kernel coming next week will take care of it, but who knows.  httpd
seems to hang and get itself stuff in an accept() loop:

accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)

Although I may have a bit of a Heisenberg here.  Whenever I point strace
at the process to get this information it seems to come unstuck.

I am using USE_USLOCK_SERIALIZED_ACCEPT right now.  FCNTL and FLOCK both
had worse problems.  Anybody else out there with some ARM-Linux insight
here?

-Rasmus

Re: Apache on the Netwinder

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> Is your client disconnecting?  Linux 2.0 reports these errors when the
> client does the handshake and disconnects before the app does accept(),
> and no other unix does.  They changed it in 2.1 because too many unix apps
> just screw up royally when given these errno (see http_main.c for the full
> list of errors that I know of).  The reason for reporting the errors is a
> suggestion in one of the host requirements RFCs... but it's not part of
> the berkeley socket API per se. 
> 
> > Although I may have a bit of a Heisenberg here.  Whenever I point strace
> > at the process to get this information it seems to come unstuck.
> 
> Yeah this is one of the annoying features of ptrace() under linux. 
> 
> Dunno what to say about the problem though.  It sounds like the kernel... 

I suspect the kernel as well.  Still waiting for a new kernel release.
The interesting thing is that Apache 1.2.6 seems to work flawlessly.

 http://netwinder.lerdorf.on.ca

There is a stress tester at:

 http://netwinder.lerdorf.on.ca/fonts.php3

That page takes a whole directory of TTF fonts and creates an image for
each using PHP and GD on the fly and serves all these images up on a page.  
Under Apache-1.3.x this page would never completely load.  Under
Apache-1.2.6 which I am currently running it works fine.

-Rasmus

Re: Apache on the Netwinder

[Dean Gaudet <dg...@arctic.org>]

On Fri, 4 Sep 1998, Rasmus Lerdorf wrote:

> I am still struggling with reliability on the Netwinder.  I am hoping the
> new kernel coming next week will take care of it, but who knows.  httpd
> seems to hang and get itself stuff in an accept() loop:
> 
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)

Is your client disconnecting?  Linux 2.0 reports these errors when the
client does the handshake and disconnects before the app does accept(),
and no other unix does.  They changed it in 2.1 because too many unix apps
just screw up royally when given these errno (see http_main.c for the full
list of errors that I know of).  The reason for reporting the errors is a
suggestion in one of the host requirements RFCs... but it's not part of
the berkeley socket API per se. 

> Although I may have a bit of a Heisenberg here.  Whenever I point strace
> at the process to get this information it seems to come unstuck.

Yeah this is one of the annoying features of ptrace() under linux. 

Dunno what to say about the problem though.  It sounds like the kernel... 

Dean

Re: Apache on the Netwinder

[Dirk-Willem van Gulik <di...@jrc.it>]

On Fri, 4 Sep 1998, Rasmus Lerdorf wrote:

> I am still struggling with reliability on the Netwinder.  I am hoping the
> new kernel coming next week will take care of it, but who knows.  httpd
> seems to hang and get itself stuff in an accept() loop:
> 
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
> accept(15, 0xbffffa88, [16]) = -1 ECONNRESET (Connection reset by peer)
> 
> Although I may have a bit of a Heisenberg here.  Whenever I point strace
> at the process to get this information it seems to come unstuck.
> 
> I am using USE_USLOCK_SERIALIZED_ACCEPT right now.  FCNTL and FLOCK both
> had worse problems.  Anybody else out there with some ARM-Linux insight
> here?

Though I am not sure what those corel boxes run, but I see the same with
an older ArmLinux 2.0 kernel on my RiscPC at home. I just upgraded
ARM-Linux 2.1 and it went away. (Though Gcc 2.8.1 seems broken. Had to
step back to 2.7). 

A diff on the kernel yieleded about a zillion changes; and there seems to
be a lot of casting going on around accept(), select() and recv() handling
of for example FD passing. Some of it assumes specific endian and lenght
insofar as I can work out.

Dw.