moore@forty2.enet.dec.com (Paul Moore) (04/08/91)
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"
INIT: Command is respawning too rapidly. Check for possible errors
id: v1 "/etc/getty /dev/vt01 vt01"
INIT: Command is respawning too rapidly. Check for possible errors
id: v2 "/etc/getty /dev/vt02 vt02"
Naturally, the system then hangs up.
Thanks in advance,
- Paulcpcahil@virtech.uucp (Conor P. Cahill) (04/08/91)
moore@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" The proble is probably one of the following: 1. /etc/getty is gone 2. /etc/gettydefs is corrupted (or at least the console, vt01 and vt02 entries are trashed) 3. /dev/console is gone or has the incorrect device numbers 4. /unix is screwed up (I would only suspect this if you recently made a new unix, or suffered some sort of system crash) Boot the system in single user mode (using the install disk) mount /dev/dsk/0s1 /mnt cd /mnt and look around to see what is going on (Note that you will have to prepend /mnt on to all the paths I specified above. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
slootman@dri.nl (Paul Slootman) (04/08/91)
In article <1991Apr8.102837.12050@hollie.rdg.dec.com> moore@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" [and a number of other inittab lines] Ummm... Go to single user mode (or maintenance mode, depending on the system). Check that a) /etc/getty is there and has execute permission, or isn't damaged in any other way b) /etc/gettydefs is there and contains the entries used by the various getty invocations, without errors (getty has a '-c file' option to check a gettydefs-type file) c) the devices are there, i.e. /dev/console, /dev/vt01, etc. and that these devices are available (ports on an expansion IO module won't be accessible if the module is disconnected or inoperational in some other way; although the console is there, as you see some messages; they might, however, be sent to /dev/syscon...) In my experience these are the things to watch for. Hope this helps. Paul. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= : slootman@dri.nl : Don't hit the keys so hard, : : ...!hp4nl!dri500!slootman : it hurts : =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
sgren@dynas.se (Johannes Sjogren) (04/09/91)
In article <1991Apr08.133110.11967@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >moore@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" I have just recently had exactly the same problem. Init complained about all my getty:s, on both console, vtxx and ttyd0. I booted my system from floppy and changed the initdefault entry in /etc/inittab to 's'. After this I was able to reboot from the hard disk and get the system up in single user mode. If I tried doing "init 2" to get to multiuser I just ended up in respawning getty-land again.. >The proble is probably one of the following: > > 1. /etc/getty is gone > 2. /etc/gettydefs is corrupted (or at least the console, vt01 and vt02 > entries are trashed) They seemed Ok on my system. I tried starting a getty manually ("/etc/getty /dev/vt01") and it started up OK and prompted on the expected virtual terminal (vt01). > 3. /dev/console is gone or has the incorrect device numbers Both /dev/console and /dev/vtxx were OK. > 4. /unix is screwed up (I would only suspect this if you recently > made a new unix, or suffered some sort of system crash) I thought my /unix could be damaged so I replaced it with an old one. No change. I also tried reinstalling the core floppys. This didn't work either. Finally I ended up doing a full re-install. Now it seem to work. -- Johannes Sjogren sgren@dynas.se DynaSoft, Dynamic Software AB Phone: +46-8-726 85 60 Liljeholmsv 10, S-117 61 STOCKHOLM, SWEDEN Fax: +46-8-18 11 45
rden@rden.gen.nz (Robert den Hartog) (04/11/91)
In article <1991Apr9.084115.1612@dynas.se> sgren@dynas.se (Johannes Sjogren) writes: >In article <1991Apr08.133110.11967@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >>moore@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" > >I have just recently had exactly the same problem. Init complained about all >my getty:s, on both console, vtxx and ttyd0. >I booted my system from floppy and changed the initdefault entry in >/etc/inittab to 's'. After this I was able to reboot from the hard disk >and get the system up in single user mode. If I tried doing "init 2" to get >to multiuser I just ended up in respawning getty-land again.. > >>The proble is probably one of the following: >> >> 1. /etc/getty is gone >> 2. /etc/gettydefs is corrupted (or at least the console, vt01 and vt02 >> entries are trashed) > [ and some more ] Had the same on Esix, after booting up on the 1st installtion floppy and installing it's /etc on my hard disk I started comparing things. Turned out that something had bitten the end off /etc/sulogin. (and is was 2 in inittab, so why did /etc/sulogin matter?) -- Why do we have alarm clocks? Surely God meant for us to sleep longer. Hey, have a nice one. Robert den Hartog. {rden|robert}@{rden|mercury}.gen.nz ...If it don't work, yell it, I like bang paths, they work.
dick@ahds.UUCP (Dick Heijne CCS/TS) (04/11/91)
moore@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.
stu@mav.com (Stu Donaldson) (04/11/91)
In article <1991Apr8.102837.12050@hollie.rdg.dec.com> moore@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" ... >Naturally, the system then hangs up. > >Thanks in advance, > >- Paul I recently (Sunday) had the same problem. In my case, it seems to me to be somewhat like black magic, but I'll share my experience with you in the hopes it may help. I recently found out about the TZ environment variable also holding the effective julian date for daylight savings time. I went to edit /etc/TIMEZONE and added a somewhat lengthy comment to the file describing the format of the variable, and complaining about having to change it each year, since daylight savings time goes into effect based on month and week, rather than on julian day. :-(. Well sometime later, I rebooted my system with the same results you described above. I tried everything I could think of. I must have rebooted the system 20 times from the install disk and verified that everything looked as it should. I noticed that /etc/init does reference the file /etc/TIMEZONE (strings /etc/init) but couldn't find a reference to TZ in the init program. On a whim, I changed the file back to a oneliner setting up TZ (with a single line comment) and amazingly the system booted just fine. I later added several lines of comments again to the file to verify my test, and found the problem had returned. Without the source to /etc/init, I surmised that init was reading in /etc/TIMEZONE into a fixed length buffer and was overwriting some internal variables with my longer file. Needless to say, I was very PISSED with such a STUPID BUG! I suspect that there is some reference to this "feature" burried deep in my incredibly accurate and friendly documentation. :-( So, has anyone else discovered this? Hope this helps someone else save 6 hours on a Sunday evening. -- Stu -- ----------------------------------------------------------------------- Stu Donaldson "Can't you understand what I'm saying?" stu@mav.com "What happened? Did you Fail Telepathy?"
jsd@proxima.UUCP (Jeremy Gryttpype Druker) (04/12/91)
In article <1991Apr8.102837.12050@hollie.rdg.dec.com> moore@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" [and a number of other inittab lines] ...and thus answered slootman@dri.nl (Paul Slootman): >Ummm... Go to single user mode (or maintenance mode, depending on the >system). Check that >a) /etc/getty is there and has execute permission, or isn't damaged in > any other way >b) /etc/gettydefs is there and contains the entries used by the various > getty invocations, without errors (getty has a '-c file' option to > check a gettydefs-type file) >c) the devices are there, i.e. /dev/console, /dev/vt01, etc. and that > these devices are available (ports on an expansion IO module won't I had exactly that same problem, (with Intel UNIX, which I believe is very similar to ISC) and battled for quite a while before ultimately reinstalling Unix :-( Even weirder was that it happened twice in one week - to 2 different machines, both of which had been running happily for months! I had checked all the things Paul Slootman suggested. I could spawn getty successfully from single-user mode on any of the terminals; it in turn would exec /bin/login correctly once a user name had been entered. getty -c was perfectly happy with gettydefs. I could start TCP/IP and rlogin from another machine. When I modified inittab and telinit q'd init would again moan about processes respawning too rapidly - even a line like name:012s:respawn:/bin/echo foo >/dev/console would not cause "foo" to appear on the console. Processes would most certainly start up - if I timed a "ps -ef" just right I'd see a <defunct> process waiting to be cleaned up, and the next process number would be 5 or so higher than the last - 'cos init spawned the inittab process 5 times before giving the error message. If it happened before, it might happen again. And next time, I'd like to fix it without reinstalling! Any other suggestions? -J ---------------------------------------------------------------------------- In a distant and second-hand set of | Jeremy Druker dimensions; on an astral plane that | jsd@proxima.UUCP was never meant to fly... | ...!uunet!ddsw1!olsa99!proxima!jsd --------------- - Terry Pratchett ----------------------------------------
richard@octel.UUCP (Richard Karasik) (04/12/91)
In your gettydefs file look to see that all of the id fields are unique .. (first field) If they are not, then this respawning problem could occur. Richard -- |UUCP richard@octel.com |VOICE (408) 942-6372 | Press 1 then divide your age by 6 - press star, then flash 3 times ....... | (No you cant get a message to me that way -but its fun watchin' you)
fred@walter.uucp (Fred Walter) (04/13/91)
sgren@dynas.se (Johannes Sjogren) writes: >cpcahil@virtech.uucp (Conor P. Cahill) writes: >>moore@forty2.enet.dec.com (Paul Moore) writes: >>>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" > >I have just recently had exactly the same problem. Init complained about all >my getty:s, on both console, vtxx and ttyd0. Did your /etc/inittab file have two or more entries with the same 'unique' identifier ? A friend's Interactive Unix had the init problem, and when the 'unique' identifiers (which came that way right out of the box, if you used the menu during the install to setup the serial ports a certain way) where changed so they really were unique, the problem went away. It was *very* annoying that it came out of the box with this problem. Not to mention sendmail kept on respawning (until it was ripped out and replaced with smail 3.1.19). Not to mention mailx will dump core when you try to respond to certain mail addresses (that mail will correctly respond to). Not to mention ... Grrr... But once all the problem software was worked around (or ripped out and replaced) it's pretty nice. fred >I booted my system from floppy and changed the initdefault entry in >/etc/inittab to 's'. After this I was able to reboot from the hard disk >and get the system up in single user mode. If I tried doing "init 2" to get >to multiuser I just ended up in respawning getty-land again.. > >>The proble is probably one of the following: >> >> 1. /etc/getty is gone >> 2. /etc/gettydefs is corrupted (or at least the console, vt01 and vt02 >> entries are trashed) > >They seemed Ok on my system. I tried starting a getty manually >("/etc/getty /dev/vt01") and it started up OK and prompted on the expected >virtual terminal (vt01). > >> 3. /dev/console is gone or has the incorrect device numbers > >Both /dev/console and /dev/vtxx were OK. > >> 4. /unix is screwed up (I would only suspect this if you recently >> made a new unix, or suffered some sort of system crash) > >I thought my /unix could be damaged so I replaced it with an old one. No >change. > >I also tried reinstalling the core floppys. This didn't work either. >Finally I ended up doing a full re-install. Now it seem to work. >-- > Johannes Sjogren sgren@dynas.se > DynaSoft, Dynamic Software AB Phone: +46-8-726 85 60 > Liljeholmsv 10, S-117 61 STOCKHOLM, SWEDEN Fax: +46-8-18 11 45 -- School address : grwalter@watmath.waterloo.edu Home address : watmath.uwaterloo.ca!xenitec!walter!fred Can you say "Thesis Avoidance" boys and girls ?
kuyper@cside1.uucp (Kuyper Hoffman) (04/15/91)
In article <4665@proxima.UUCP> jsd@proxima.UUCP (Jeremy Gryttpype Druker) writes: >In article <1991Apr8.102837.12050@hollie.rdg.dec.com> moore@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" >[and a number of other inittab lines] > >...and thus answered slootman@dri.nl (Paul Slootman): > >>Ummm... Go to single user mode (or maintenance mode, depending on the >>system). Check that >>a) /etc/getty is there and has execute permission, or isn't damaged in >> any other way >>b) /etc/gettydefs is there and contains the entries used by the various >> getty invocations, without errors (getty has a '-c file' option to >> check a gettydefs-type file) >>c) the devices are there, i.e. /dev/console, /dev/vt01, etc. and that >> these devices are available (ports on an expansion IO module won't > Hmmmm, I had something real similar about 16 months ago. I had been fiddling in the file /etc/TIMEZONE and had inserted our local zone name and Greenwhich offset, but being naturally cautious by nature had decided to keep the original zone hashed out as a comment on the line above our own zone. Certainly it is allowable to have # comments in /etc/TIMEZONE, so my file looked like this: ---------- /etc/TIMEZONE ---------- #ident "@(#)adm:TIMEZONE 1.2" # Set timezone environment to default for this machine # TZ=EST5EDT TZ=SAT-2 export TZ ---------- EOF ---------- Some days later I rebooted the machine (without making any configuration changes whatsoever. Everything went kinda OK, but would the damn thing boot properly, no way.... and as I remember it the error that I got on the console was exactly what you describe, so just check that you (or someone else) hasn't changed that file. The problem seems to be that init scans the file blindly looking for TZ (without parsing) and then uses the entire line and gets hellishly confused by the #. >I had exactly that same problem, (with Intel UNIX, which I believe >is very similar to ISC) and battled for quite a while before >ultimately reinstalling Unix :-( Even weirder was that it >happened twice in one week - to 2 different machines, both of >which had been running happily for months! Again, a change on Monday is seldom remembered on Wednesday.... > I could start TCP/IP and rlogin from another machine. Can't remember if I could do this.... Hope this helps Kuyper -- | Kuyper Hoffman | Life is just a bowl of All-Bran | | kuyper@cside1.UUCP | You wake up every morning | | ....!ddsw1!olsa99!oct1!cside1!kuyper | And it's there.... | \--------------------------------------/ \--------------------------------/