fedor@uu.psi.com (Mark S. Fedor) (02/23/90)
We are running a Sun 3/280 and a SPARCserver 370 with sunOS 4.0.3. Every so often, no one can telnet into these machines. You get a "connected to ..." message, but you never get a login: prompt. The only way to fix this problem is to do a reboot of the entire system. After this, you can telnet in fine! When this event occurs, everything else works fine. People are able to "rlogin" to the machine, etc. only telnet'ing *in* to the machine is broken. My question is, has anyone else witnessed this behavior? Is it a problem with the "in.telnetd" server? Is there a fix? Thanks. Mark fedor@uu.psi.com
medin@cincsac.arc.nasa.gov (Milo S. Medin) (02/24/90)
I don't think your problem is in in.telnetd. We had the same problem here. It turned out to be /bin/login hanging. If you see a /bin/login -h hostname -p hanging around the same ptys that the telnetd is attached to, you have the problem I am talking about. The cause is that inetd was manually restarted from a shell, and thus inherited the environment of it's parent process. It's this environment that causes things to wedge, because the -p flag to login tells it to preserve the environment, and the environment that it inherits from inetd screws it up. Rebooting the system creates a fresh inetd, minus the contaminating environment. SUN knows about this, and it's fixed in 4.1, due out soon. I forget the bug #, but if you tell this to your system support people, they can probably get it from SUN. Thanks, Milo
rcodi@koel.co.rmit.oz.au (Ian Donaldson) (02/26/90)
medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: >I don't think your problem is in in.telnetd. We had the same problem >here. It turned out to be /bin/login hanging. ... >The cause is that inetd was manually restarted from a shell, and thus >inherited the environment of it's parent process. It's this environment >that causes things to wedge, I found this problem under 4.0.3 too, and found that there were at least two problems. When I ported 4.3-tahoe version of /bin/login to SunOS 4.0.3 to see what was going on, I found that the environment was being stomped on. I did a "w" and found my encrypted passwd in the output! The solution was to initialize the variable "envinit" inside "login.c" to prevent setenv() from stomping randomly on memory. ie: char *envinit[] = {0}; Without this, anything could happen to /bin/login. It could hang, crash or anything, and would be influenced by the size of the environment or the number of arguments it was passwd by its invoker (eg: inetd). If inetd was restarted from a shell then this size would differ, producing different results. HOWEVER, replacing /bin/login under 4.0.3 didn't cure the telnet problem. Compiling up a stock 4.3-tahoe telnetd and installing it *did* fix the problem, instantly. I reverted to the 4.0.3 /bin/login once telnetd was replaced and it still worked ok (so far). (Incidently, it was a Sun 3/80, running 4.0.3 EXPORT) Ian D