system console message

[Jeff Hagstrom]

INIT: COmmand is respawning too rapidly.
Will try again in 5 minutes.
Check for possible errors
id:cons "/usr/sbin/getty console console"

What is going on and why? What do I have to do to fix it?

[Bruno Vidal]

Hi,
It seams that your getty command died, so init try to restart it. Now you need to check why getty died:
-is the command still exist
-does it has the execution bit
-is /dev/console still there
-etc.....

Cheers.

[T. M. Louah · Accepted solution]

need to boot into single user mode
by resetting system & interrupting boot process, at BCH typ in "bo pri" to boot from primary disk
Now answer Yes to interact with IPL
at ISL> hpux -is
system will boot at this point no command will work you need to mount manually /usr & /var
.: mv /etc/inittab /etc/inittab.old
.: cp /usr/newconfig/etc/inittab /etc/inittab
.: run init q

Now more investigation is required.
Cheers,
T??

[Darren Prior]

Hi,

There are a couple of possibilities:

1) something in /etc/inittab that shouldn't be there. A previous response showed one way to put the default inittab into place. If it's something that you've added to inittab, consider using an rc script for it instead.

2) someone has placed a script in /etc/rc.config.d. The files in here should only contain variable setting, rather than scripts. Start reading through any files that have dates more recent than your last reboot.

regards,

Darren.

[Bill Hassell]

The most common reason is that there are getty entries in /etc/inittab for serial devices (modems or terminals) that do not exist. getty is being told to run and read these non-existant devices, getting an unexpected response and then gets restarted by init over and over. Edit inittab and comment out all getty entries (except the console). Then run init q to re-read the inittab file. This will eliminate the messages. Now look at your system to see if there are any serial devices other than the console. If so, enable just those specific devices in inittab.

[doug mielke]

another common cause is failure to sync. comm speed to the tty device.

The last entry in the /etc/inittab for a getty refers to a label in the /etc/gettydefs file. i.e. 1200

In that file the label 1200 is followed by a bunch of serial comms parameters/commands, then another label, say, 2400. The getty then tries that label, 2400, and so on.

this allows the getty to try multiple speeds until it synchs. HP seems to like slow first, then get faster. Some devices, (common on long cable runs) don't respond quickly enough to sync.

If you change the last entry for that label in gettydefs to match the label itself, ( 1200 1200) you can 'lock' the comm speed. (some in gettydefs are already like that)