ISC TCP/IP 1.2 hangs?

[Karl Denninger]

In article <1991Jun19.013909.690 at pinhead.pegasus.com> todd at pinhead.pegasus.com (Todd Ogasawara) writes:
>
>Well, I spoke too soon... ISC TCP/IP 1.2 hung twice more today and the
>procedure I described above didn't work. I had to run /etc/shutdown and
>reboot the machine to get TCP/IP working again.

I've seen this one.

>It also appears that this problem is not uncommon and has been around since
>version ISC TCP/IP 1.0. This implies that I should not expect it to work
>any better when ISC TCP/IP 1.3 comes out.

The worse problem is that any socket which is left in an "accept" state (ie:
waiting for requests) or active for long periods of time will eventually end
up hanging as well -- in a closed, inaccessible state.

Unless you're looking at that particular port, all appears well.  This means
a network monitor which "pings" it once in a while will report all is ok --
but it most certainly is not!

We have the ported LPR/LPD combination, as well as smail3.  Both will hang
up if left in daemon mode.  Smail3 has a solution -- start it from inetd.

LPR/LPD, unfortunately, doesn't -- so you end up with printers that just
"detach" themselves, and printed files pile up on the user's station.

The only way to clear it is to kill all existing processes that have the
port open, and restart the daemon.

Not at all impressive.

This is the only OS (out of 3 other vendors here at NAITC) that I've seen do
this.  ISC hasn't managed to fix it right in three tries.

--
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning at nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.