[comp.sys.pyramid] Problem with inetd - stops forking in.telnetds

pmcmahon@ukpyr3.uk.oracle.com (Peter McMahon) (07/02/90)

Folks.  The problem is this.  An inetd on a pyramid here occasionally
``hangs'' and won't fork any new telnetds.  The facts are as follows:

	+ It always works for some hours/days after a reboot
	+ It only stops working for telnet (although this is probably
	  its biggest customer).  Rlogins (for example) are fine.
	+ According to netstat -a, it continues to listen on port 23
	+ The box is a MIServer 2/12 running OSx5.0.
	+ It's almost brand new

We have a workaround.  We can edit /etc/servers, comment out telnet and
HUP the daemon.  It stops listening on port 23.  We can then start up another
inetd off an alternate config file that tells it to listen for telnet 
alone.  This (suprisingly enough) works, although the replacement daemons
often develop the same problem in time.

The local pyramid people tell us it's never been seen before.
Any suggestions?  Anyone else bitten by this?

Peter McMahon					Email: pmcmahon@oracle.com
Operations Support				Phone: +44 344 41 5007	
Oracle U.K, 
The Ring, Bracknell
RG12 2XY, UK

keany@sequent.UUCP (Bernard Keany) (07/03/90)

In article <1990Jul2.143124.27559@oracle.com> pmcmahon@oracle.com (Peter McMahon) writes:
>Folks.  The problem is this.  An inetd on a pyramid here occasionally
>``hangs'' and won't fork any new telnetds.  The facts are as follows:
>
>	+ It always works for some hours/days after a reboot
>	+ It only stops working for telnet (although this is probably
>	  its biggest customer).  Rlogins (for example) are fine.
>	+ According to netstat -a, it continues to listen on port 23
>	+ The box is a MIServer 2/12 running OSx5.0.
>	+ It's almost brand new
>
>We have a workaround.  We can edit /etc/servers, comment out telnet and
>HUP the daemon.  It stops listening on port 23.  We can then start up another
>inetd off an alternate config file that tells it to listen for telnet 
>alone.  This (suprisingly enough) works, although the replacement daemons
>often develop the same problem in time.

just a shot in the dark ... are you over-running the TOOMANY
variable; if this problem "clears" in 10 minutes or so you've probably
started more than 40 in a specified amount of time.


-- 
Bernie Keany		"That's my story and I'm sticking to it"
..sequent!keany