Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!oliveb!sun!limes From: limes@sun.com (Greg Limes) Newsgroups: comp.unix.questions Subject: Re: What's wrong with my inittab? Message-ID: Date: 30 Jun 89 02:30:12 GMT References: : <2048@csuna.csun.edu> Sender: news@sun.Eng.Sun.COM Followup-To: comp.unix.questions Organization: Sun Microsystems, Inc. Lines: 33 In-reply-to: abcscnge@csuna.csun.edu's message of 24 Jun 89 22:16:18 GMT [showing off my ignorance to the world again, but what's new] In article <2048@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott "The Pseudo-Hacker" Neugroschl) complains about his System-V box starting a getty for a serial port, and having a "ps -ef" line that reflects that its controlling TTY is "?". Scott, all my experience is on BSDish boxes, but it seems to me that this would be the same across both sides of the world. Commonly, this happens when the "getty" is attempting to open a serial port with hardware carrier detect set up, and is being blocked in the open() call until the serial line's DCD line. Look carefully at where the genederchangers and nullmodems end up connecting pin 8 on your VME box's interface. This is probably the signal that needs to be asserted before your getty is freed to execute. This is just a guess, it may be pin 6 or even somewhere strange; check your documentation for specifics. If your AT box is kind enough to assert DTR only when the port is open, connect the PC's DTR (probably on pin 20) to the VME's DCD (again, probably on pin 8); when the PC "dials up" the VME, it will open the gates for the getty. The benefit of this arrangement is that if the PC hangs up (drops DTR), the session on the VME box will (probably) be killed off. This is all generalizing from another varient of unix, thus all the weasal wording ... hope it puts you onto the track of the problem. -- Greg Limes [limes@sun.com] Nearly Reformed Hacker -- Greg Limes limes@sun.com ...!sun!limes 73327,2473 [chose one]