Re: os-unixware/1499: Server ceases answering requests, remains running silently despite SIGUSR1 or SIGHUP. (fwd)

[Marc Slemko <ma...@znep.com>]

The following reply was made to PR os-unixware/1499; it has been noted by GNATS.

From: Marc Slemko <ma...@znep.com>
To: Apache bugs database <ap...@apache.org>
Cc:  Subject: Re: os-unixware/1499: Server ceases answering requests, remains running silently despite SIGUSR1 or SIGHUP. (fwd)
Date: Thu, 4 Dec 1997 16:49:10 -0700 (MST)

 ---------- Forwarded message ----------
 Date: Thu, 4 Dec 1997 15:25:43 -0800
 From: David Alan Pisoni <da...@cnation.com>
 To: marc@hyperreal.org
 Subject: Re: os-unixware/1499: Server ceases answering requests, remains running silently despite SIGUSR1 or SIGHUP.
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Content-Transfer-Encoding: quoted-printable
 
 >Synopsis: Server ceases answering requests, remains running silently=
  despite SIGUSR1 or SIGHUP.
 >
 >State-Changed-From-To: open-analyzed
 >State-Changed-By: marc
 >State-Changed-When: Wed Dec  3 14:55:36 PST 1997
 >State-Changed-Why:
 >Do you have all the latest SCO networking patches applied?
 >Traditionally, SCO stuff has often had broken networking.
 >
 
 No, I just checked on that.  I found a recently posted omnibus network=
  patch, but was unable to apply it because of a glitch (it wasn't=
  recognizing my OS version.)  I've contacted SCO about the problem, they=
  should respond within the milennium.
 
 >If you can, give it a try using gcc for a compiler.  This has sometimes
 >resolved such problems.
 >
 
 I have had problems with the gcc distributed at the SCO FTP site, and=
  haven't had the time (or wherewithal) to go through the lenghty source=
  compiliation process required for a good gcc build.
 
 >What happens when it doesn't answer requests? Are connectiosn refused?
 >Do you connect and just have nothing answer? =20
 The latter occurs.  Nice happy TCP 80's appear in the netstat, and the=
  client will report "Host Contacted, waiting for reply", but just silence.
 =46YI - I attempted to access the web server (when in this state) from the=
  same machine (I used telnet), then looked at netstat.  The client process=
  was in "FIN_WAIT_2", while the server process was in "ESTABLISHED" (I=
  believe. I don't remember exactly.  I just remember think it very strange."
 
 Ahh, just tried it again, but with a different result (though I made a=
  configuration change, explained below.) =20
 
 >What is running in the way of processes when this happens?
 
 I imagine around 15 or so, which I think is what I have startservers set at.
 
 >Anything in the error log?
 Nope.
 
 >If SCO has something like ktrace/strace/ptrace/truss/etc.
 >to trace system calls, see what the child processes are doing.
 >Try using a debugger on the child processes after recompiling
 >with -g in EXTRA_CFLAGS to see where they child processes
 >are when it hangs.
 
 Before I dive into that, I wanna try the network patches.
 
 Okay, since my last contact, I changed the configuration to disable all the=
  "Listen" directives and their cooresponding Vhosts.  I had hoped this would=
  be a temporary fix.  No such luck, though the behaviour seems more consista=
 nt.
 Now the netstat table is filling up with mostly 'CLOSE_WAIT's and to a=
  lesser degree 'ESTABLISHED's, with a small handful of 'FIN_WAIT_1's.  The=
  server is now actually refusing connections, as opposed to opening them and=
  then ignoring them.  This looks more and more like a kernel networking=
  problem, but I will get back to you after I get the damn patch installed. =
  This doesn't cause a general denial of service -- only the web server=
  hangs, but I can telnet in to HUP it.  Oh, and I forgot to mention, in it's=
  present state (after changing the configuration) it now recovers with a HUP=
  (where previously it quietly logged the HUP but still did not change its=
  abberant behaviour.)
 
 In short, I think that there is a kernel networking problem causing my aches=
  now, but I'm not sure if the patch will fix the problem with multiple=
  "Listen"s (which was supposedly fixed by USE_FCNTL_SERIALIZED_ACCEPT.) =20
 
 I will get back to you with what I discover.
 
 Thanks for your time,
 
 
 David Pisoni, System Administrator
 CyberNation, LLC -- Web Design for the Next Milennium
 david@cnation.com - http://www.cnation.com/
 310/656-3450  -  310/656-3453 (fax)
 
 
 -----BEGIN PGP SIGNATURE-----
 Version: PGP for Personal Privacy 5.0
 Charset: noconv
 
 iQA/AwUBNIc8Aj8po64ro8iIEQJ/fgCgwcjcKxNmhgufpCxNPuijcz5qRz4AniTl
 IfnqLq5WuYNtKni8TU7+fghw
 =OcMT
 -----END PGP SIGNATURE-----