slevy@nic.MR.NET (Stuart Levy) (03/19/89)
I'm hoping some or many of you have dealt with this problem before. /etc/inetd dumps core on our IRIS 4-D (4D1-3.147) at the first connection attempt, if we have yellow pages enabled. (Its YP server is then a Sun running SunOS 3.5.) YP appears to work fine otherwise on things like passwd and hosts lookups. Inetd runs as expected when we just disable YP. This is tolerable but it'd be nice to have it. Inetd starts up normally, listening on the right ports (telnet, ftp, rsh etc); the first connection attempt succeeds and then is immediately dropped, as inetd leaves a core dump. It appears to be doing something like FD_ISSET with an fd of -1 -- which causes a crash since it's treated as unsigned and so tries to index in its array with a huge offset -- but it's too hard to trace where that number came from. Any clues would be appreciated! Stuart Levy slevy@geom.umn.edu (or slevy@nic.mr.net or slevy@uc.msc.umn.edu) === By the way, in the exchange on sending ICMP port unreachables in reply to routing packets: hosts are not supposed to send error replies to broadcasts, as routing packets (including RIP) generally are. They should be ignored unless addressed specifically to that host. This could indicate an SGI software bug or disagreement over the broadcast address or both. It might be possible to make the error messages disappear by setting the IRIS's broadcast address to whatever address the broadcasts are being sent to, if 3.5 allows that.
robert@shangri-la.gatech.edu.gatech.edu (Robert Viduya) (03/20/89)
> /etc/inetd dumps core on our IRIS 4-D (4D1-3.147) at the first connection > attempt, if we have yellow pages enabled. (Its YP server is then a Sun > running SunOS 3.5.) YP appears to work fine otherwise on things like passwd > and hosts lookups. Inetd runs as expected when we just disable YP. This is > tolerable but it'd be nice to have it. We had this problem a few weeks back and tracked it down to the fact that sgi's inetd expects a few specific entries in the /etc/services file. Since the /etc/services file is yp'ed and sun's default services file doesn't include the ones that sgi's inetd expects, inetd just gives up and dumps core. We fixed the problem by copying the entries for "bootpc", "chargen" (both of them), "ntalk" and "bootp" from sgi's /etc/services file to the services file on the sun yp server. Inetd hasn't complained since. robert -- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275
spike@adt.UUCP (Joe Ilacqua) (03/20/89)
<> /etc/inetd dumps core on our IRIS 4-D (4D1-3.147) at the first connection <> attempt, if we have yellow pages enabled. (Its YP server is then a Sun <> running SunOS 3.5.) YP appears to work fine otherwise on things like passwd <> and hosts lookups. Inetd runs as expected when we just disable YP. This is <> tolerable but it'd be nice to have it. < <We had this problem a few weeks back and tracked it down to the fact that sgi's <inetd expects a few specific entries in the /etc/services file. Since the </etc/services file is yp'ed and sun's default services file doesn't include <the ones that sgi's inetd expects, inetd just gives up and dumps core. I can confirm this too. I simply merged the Sun and 4D services files (there were no conflicts) and have had no problems since. However be warned that if you have programs which use getpwent(3C) (et al), they must be linked with '-lsun -lbsd'. If they where not they will not use yp and will not be able to find users in the password file. This is documented, but a bit of a pain. Joe Ilacqua Associative Design Technology
tim@ZORAC.DCIEM.DND.CA (Tim Pointing) (03/24/89)
I had similar problems with inetd using YP from another system (a Sun). I think the problem stems from inetd not finding one of the executables listed in "/usr/etc/inetd.conf" (the x-server line.) After I commented out that line (and the other couple of lines which weren't mentioned in the YP servers services but were in the inetd.conf file. We seem to be running just fine now. Tim Pointing, DCIEM tim@zorac.dciem.dnd.ca