home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vxworks / 686 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  2.8 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!dog.ee.lbl.gov!lbl.gov!vxwexplo
  2. From: Bob Foery <bobf@verdix.com>
  3. Newsgroups: comp.os.vxworks
  4. Subject: re: Tcp dying
  5. Date: Thu, 30 Jul 92 16:12:09 +0100
  6. Organization: Lawrence Berkeley Laboratory, Berkeley CA
  7. Lines: 82
  8. Sender: vxwexplo@lbl.gov
  9. Message-ID: <9207302012.AA01859@sequoia.hq.verdix.com>
  10. NNTP-Posting-Host: 128.3.112.16
  11. Originator: daemon@vxw.ee.lbl.gov
  12.  
  13.  
  14. ==Submitted-by thor@surt.atd.ucar.edu  Thu Jul 30 12:01:33 1992
  15. ==Submitted-by: thor@surt.atd.ucar.edu (Richard Neitzel)
  16. == 
  17. ==We run some VxWorks targets off of an IPC. Two of these targets read
  18. ==in several files to load some DSP boards. If the two try to perform
  19. ==this task at the same time the IPC gets this error message on the
  20. ==console:
  21. ==
  22. ==odin inetd[121]: shell/tcp server failing (looping), service terminated
  23. ==
  24. ==The only why we know to recover is to send inetd a -1 signal.
  25. ==
  26. ==So
  27. ==
  28. ==A> What is the probable cause of this?
  29. ==B> What can we do to recover and/or prevent this?
  30.  
  31. Richard,
  32.   This problem has reared its ugly head before.  It is a known SunOS bug.
  33. The patch-ID for this problem is 100178-06.
  34.  
  35.   I can e-mail you this patch if you'd like.  As a matter of fact, since this
  36. is the second time this has surfaced, I would be happy to submit this patch to
  37. the archives, give some information on how to do this.
  38.  
  39.   Here is an excerpt from the README file associated with this problem:
  40.  
  41. Patch-ID# 100178-06
  42. Keywords: broken server detection
  43. Synopsis: SunOS4.0.3;4.1;4.1.1: inetd "broken server detection"
  44.           breaks on fast machines
  45. Date: 28/Aug/91
  46.  
  47. SunOS release: 4.0.3, 4.1, 4.1_PSR_A, 4.1.1
  48.  
  49. BugId's fixed with this patch: 1030599
  50.  
  51. Architectures for which this patch is available: Sun3, 3x, 4, 4c,
  52.  
  53. Patches which may conflict with this patch:
  54.  
  55. Obsoleted by:  SunOS 5.0
  56.  
  57. Update -06 [28-Aug-91]
  58. updated the sun4PSR_A object module.  The source code did not change.
  59. _________________________________________________________________________
  60.  
  61. Problem Description:
  62. inetd refuses to accept more than 40 connects per minute on a
  63. particular socket (loop detection)
  64.  
  65. The SS1 is fast enough, that you can end up legitimately calling
  66. rsh more than 40 times per minute.
  67.  
  68. This patch adds a new argument, "-r", to inetd that allows you to
  69. specify number of connections allowed in the given time in seconds.
  70. The default is to allow 40 connections in a 60 second period, E.G:
  71.  
  72. /usr/etc/inetd -r 40 60
  73.  
  74. Typically for a faster machine you might up this to 60 connections
  75. per minute, E.G:
  76.  
  77. /usr/etc/inetd -r 60 60
  78.  
  79. You will need to edit /etc/rc to make the change perminant each
  80. time the machine is rebooted, E.G:
  81. ...
  82. ...
  83. if [ -f /usr/etc/inetd ]; then
  84.         inetd -r 60 60;                  echo -n ' inetd'
  85. fi
  86. ...
  87. ...
  88.  
  89.  
  90. I hope this helps!
  91.  
  92. Bob Foery
  93. Verdix Corporation, Herndon, Virginia
  94. bobf@verdix.com
  95.