INIT: Command is respawning too rapidly...

Dick Heijne CCS/TS dick at ahds.UUCP
Thu Apr 11 20:33:14 AEST 1991


moore at forty2.enet.dec.com (Paul Moore) writes:
>>Can someone help me with this problem when I boot up my ISC-based system. I get
>>the following series of messages displayed on the terminal:
>>    INIT: Command is respawning too rapidly. Check for possible errors
>>    id: co "/etc/getty console console"

Assuming that /etc/getty hasn't passed away (this might cause the trouble)
the most probable cause is a wiring problem, that causes getty to die soon
after it started.
You can figure out this by noticing what happens:

	If the terminal does not assert DTR, which should be connected to
	DSR and DCD (pins 6 & 8 on a 25-pin computerport), getty will not
	be able to open the port and will sleep until the pins come up.

	If, however, getty succeeds in opening the port, i.e. because DSR
	on the port IS asserted, but DCD is not, getty will die immediatly
	after the open, caused by a SIGHUP. This signal is not related to
	DSR, only to DCD and is detected AFTER the port is opened.
	Some manufacturers use weird (creative) wiring systems, which can
	easily fall into this.

	A secure wiring system is:
 	      - cross-connect 4(RTS) and 5(CTS), or short-cut them
		local on each end (so, on short-cut no end-to-end
		wiring!)
	      - short-cut 6(DSR) and 8(DCD) on one end and connect
		them to DTR(20) on the other end. Also the other
		way around (so, crossed)
	      - off course, cross-connect 2(TXD) and 3(RCD) 
	      - connect 7(SG) to 7 on the other end
	      - Be sure that 1(Shield or Frame Ground) is only connected
		on ONE side, thus prohibiting capacitive distortion

	When getty runs on the port, switch on your terminal while a
	break-out box whith LED's is connected between the port and the
	cable-connector. Now, the led's 2 and 3 should be negative
	(on most boxes green), while 4,5,6,8 and 20 should be positive
	(i.e. red). Of course, 7 and 1 (the grounds won't lit).
	Check both sides.

	If all this is true and the problem still occurs the problem gets
	much more interesting...

Good luck,

Dick.



More information about the Comp.unix.sysv386 mailing list