The problem :
We have a Sparc 10/41 server running Sunos 4.1.3 dedicated to running a
gopher service.
When we attempt to index the menus (using Jughead or gophertree)
the gopher server is terminated with the following message :
inetd[140]: gopher/tcp server failing (looping), service terminated
Here is a portion of inetd.conf that relates to gopher :
# Gopher Server
gopher stream tcp nowait root /usr/local/etc/start-gopherd
start-gopherd
The script /usr/local/etc/start-gopherd contains
#!/bin/sh
#
#Start gopherd for inetd, as it won't accept more than 5 arguments!!! :-(
#
/usr/local/etc/gopherd -Iu nobody -l /var/adm/gopherlog /home/data1/CIS 70
The solution :
fitting patch 100178-08
Amongst other things this patch fixes the following :
Bugid 1030599:
inetd refuses to accept more than 40 connects per minute on a
particular socket (loop detection)
The SS1 is fast enough, that you can end up legitimately calling
rsh more than 40 times per minute.
This patch adds a new argument, "-r", to inetd that allows you to
specify number of connections allowed in the given time in seconds.
The default is to allow 40 connections in a 60 second period, E.G:
/usr/etc/inetd -r 40 60
Typically for a faster machine you might up this to 60 connections
per minute, E.G:
/usr/etc/inetd -r 60 60
You will need to edit /etc/rc to make the change permanent each
time the machine is rebooted, E.G:
...
...
if [ -f /usr/etc/inetd ]; then
inetd -r 60 60; echo -n ' inetd'
fi
Thanks to :-
tkevans@eplrx7.es.duPont.com (Tim Evans)
Mike Raffety <miker@il.us.swissbank.com>
Pauline van Winsen - Uniq Professional Services <pauline@uniq.com.au>
(Andrew Lister - SUN Tech Support)
Gordon.Rowell@nms.otc.com.au (Gordon Rowell)
dhesi@cirrus.com (Rahul Dhesi)
glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
There were some other suggestions which I didn't try
>>> John C. Hasley hasley@bgsu.edu suggested
You can drop the '70', which is the default port number for Gopher.
That should then drop you to the 5 argument limit. If I remember
correctly, you can also compile in the home directory (SERVERDATA in
Makefile.config). That would drop another one. Saves your firing up a
/bin/sh for every connection.
Since your machine is dedicated to Gopher use (even if it is merely a
major part of the usage), wouldn't you get better performance if you
had gopherd running continuously, rather than being fired up for each
request?
That would also get around your inetd problem. (Presumably the limit
is there to prevent something from going wrong and grabbing all the
available CPU cycles in calling some inetd-spawned process. It's a
safety mechanism that I wouldn't want to play with until I was sure
of what was going on.)
>>> Ilkka Virtanen <ilkka@ee.oulu.fi>
you can replace inetd with a pd munetd
>>> mikem@ll.mit.edu (Michael J Maciolek)
I'm not sure that the problem is directly caused by inetd's 40-instance
limitation. Before you try to solve the problem with a replacement for
inetd, let me make a simpler suggestion.
Modify your startup script so it exec's the real gopherd. The script
/usr/local/etc/start-gopherd should contain:
#!/bin/sh
#
#Start gopherd for inetd, as it won't accept more than 5 arguments!!!
:-(
#
exec /usr/local/etc/gopherd -Iu nobody -l /var/adm/gopherlog
/home/data1/CIS 70
^^^^
This is very important! Without it, the start-up script runs the
gopherd as a child process, and it (the child process) doesn't inherit
a connection to the initiating process. Let me try to explain that a
little better.
By using 'exec', you cause the gopherd to "take over" the thread of
execution which was started by inetd and passed on to the script. This
execution thread includes all open file descriptors (including any
descriptors associated with "live" tcp port connections) which would
otherwise not be passed on.
(and, in fact, under your current implementation, those descriptors are
NOT being passed on, which may be why your gopher requests are
failing.)
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:04 CDT