inetd weirdness

[Jack F. Vogel]

In article <396 at itcatl.UUCP> robin at itcatl.UUCP (Robin Cutshaw) writes:
[ original problem description deleted...]
 
>After tinkering around a bit, I've found the problem!  It seems that if
>your last line in /etc/inetd.conf includes a command that has multiple
>arguments, inetd will go into an infinite loop reading EOF.  I had
>uncommented the last line in inetd.conf that included rpc and that's
>when it broke.  All I had to do was enter a # on the next line and it
>worked fine.
>
>The fix: (after tinkering on a source machine)
>
>	there is a call to ungetc (only one) in inetd.c.
>	place the line "if (c != (char )EOF)" before this line
>	and it will work just fine.  Sloppy problem of ungetc'ing EOF.
>
>IBM, are you listening???
 
Robin,
	The way in which changes get made or the way in which IBM "listens"
to problems is a bit more formal than posting something to the net. What
needs to happen is that a formal report of a bug is submitted, this is
called an APAR. The APAR is evaluated by support and if needed is the basis
of a programming change. In some cases all evaluation and changes will 
happen within IBM support, in difficult ones they will make their way back
to us at Locus (the buck really stops here at this point :-}).
	In this particular case, however, a report will not be necessary
since I believe the problem is already known. Also, I checked the 4.3tahoe
source for inetd.c and it appears to be the same, so if the behavior
does not occur there then I suspect the problem is in the library and
not inetd itself. In any case it will be fixed.
	As you can see, we are listening :-}!

Disclaimer: This is in no way an official statement of IBM or Locus.

--
Jack F. Vogel			jackv at seas.ucla.edu
AIX Technical Support	              - or -
Locus Computing Corp.		jackv at ifs.umich.edu