Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
INIT: command respawning too fast
- Thread starter paulywog
- Start date
Usually this is a cable/adapter issue. Either a pin on an adapter is damaged, causing signal loss or a cable is damaged resulting the same. It could also be that the cable is not seeded correctly. Try changing out the cable and/or adapter for the serial device (/dev/tty1) and see if that helps.
crowe
crowe
Guest_imported
New member
- Jan 1, 1970
- 0
- 0
- 0
i got from IBM AIX site
this maybe of help to you.
===========================================================
How the error occurs
In general, the "respawning too rapidly" message is sent by the system to warn users that there is a problem on the tty port and that too many gettys, or "login heralds," have been requested for that port.
One exception to this error exists when upgrading to AIX level 4.2 or 4.3. This exception appears as a tty_respawn error to the system console and occurs because of an entry in the /etc/security/limits file. This entry could exist in the default stanza or the root stanza. Consider the following example: this file with the root cpu entry set to 0 will cause this error.
default:
fsize = 2097151
core = 2048
cpu = 3600
data = 262144
rss = 65536
stack = 8192
root:
cpu = 0
Remove the cpu = 0 from the stanza so the system will boot correctly and provide a login on the console. Or, you may still have the "unlimited" setting for the "cpu =" option rather than removing the option altogether from the /etc/security/limits file. Change it to the standard setting for "unlimited," which in AIX 4.3.2 and 4.3.3 is -1, as in cpu = -1.
See Causes and suggestions - number 5
The following scenario shows how the respawing error may occur. Note that the timing numbers shown below may change in later versions of AIX.
The system spawns a getty and sends a "login herald" to the terminal on tty0.
Loose cabling on the terminal causes line-noise which forces a new getty to be spawned.
The system is keeping track of the total number of gettys spawned for tty0 within a three minute and 45 second period; if that number exceeds five, then an error is displayed on the console and the system shuts down the port.
Note: You can duplicate this yourself by logging in and out of the terminal several times very quickly within the above mentioned time span.
The port will stay in a suspended state for about 19 minutes or until the system administrator "enables" the port again. At the end of the 19 minutes, the system will automatically enable the port.
Note: PTF IX37168 changes the amount of time that the port is suspended from 19 minutes to a maximum of 240 seconds.
------------------------------------------------------------
Causes and suggestions
Modem devices are the most likely causes of the "respawning" error.
Suggestions for HAYES compatible modems:
Connect to the modem and examine the active profile.
Carrier detect should not be forced high ("&C0"
; it should be set for "&C1" with the command AT&C1.
In the active profile, verify that "result codes" is either turned off or set to "originate only". Try turning result codes off with "ATQ1".
The "timeout" or "TIME before advancing to next port setting" is set to a value other than 0 for ttys connected directly to terminals.
A port is defined and "enabled" but no cable or device is attached to it.
Suggestions:
"Pdisable" the port and remove the device.
Bad cable or loose connection.
Suggestions:
Verify that the cabling is IBM cabling or that it meets the same standard.
Check for loose connections.
Check for bent pins at the connections.
Replace the cable (as a test) with an IBM serial cable, PN: 6323741.
Corruption/tampering with the /etc/environment or /etc/inittab file.
Suggestions:
If possible, compare these files against known good copies.
Make backup copies of the files and make changes as needed.
In /etc/environment, remove any lines that are not 1) blank lines, 2) comment lines, or 3) variable=<something>.
In /etc/inittab look for strange settings on tty. Sometimes these are customized to fit certain applications (such as the Pic Blue operating system). If the tty is set to off, it is probably not being used and should be checked. Remove any inconsistencies.
Check your error report log with the errpt -a | pg command. Look for errors associated with tty software and/or hardware (e.g. "buffer overruns", "lion_box", or "concentrator" errors).
Suggestions:
If you find hardware errors ("lion_box died", for example), first make sure a user did not cause the error. Then contact your CE (customer engineer). When reporting the problem, mention all errors, including software-related ones.
Note: Certain buffer errors can be caused by faulty hardware.
Noise on communication line.
Suggestions:
Verify that cabling is the correct length and impedance; also check that toroid rings are in place where needed on longer cables.
Check the routing of cables - they should not be close to fluorescent lights, motors, or other high line-noise sources.
Again, verify that cable connections are tight.
TTY configuration is corrupted.
Suggestions:
Try deleting the tty via smit and then re-adding it.
Hardware is defective.
Suggestions:
this maybe of help to you.
===========================================================
How the error occurs
In general, the "respawning too rapidly" message is sent by the system to warn users that there is a problem on the tty port and that too many gettys, or "login heralds," have been requested for that port.
One exception to this error exists when upgrading to AIX level 4.2 or 4.3. This exception appears as a tty_respawn error to the system console and occurs because of an entry in the /etc/security/limits file. This entry could exist in the default stanza or the root stanza. Consider the following example: this file with the root cpu entry set to 0 will cause this error.
default:
fsize = 2097151
core = 2048
cpu = 3600
data = 262144
rss = 65536
stack = 8192
root:
cpu = 0
Remove the cpu = 0 from the stanza so the system will boot correctly and provide a login on the console. Or, you may still have the "unlimited" setting for the "cpu =" option rather than removing the option altogether from the /etc/security/limits file. Change it to the standard setting for "unlimited," which in AIX 4.3.2 and 4.3.3 is -1, as in cpu = -1.
See Causes and suggestions - number 5
The following scenario shows how the respawing error may occur. Note that the timing numbers shown below may change in later versions of AIX.
The system spawns a getty and sends a "login herald" to the terminal on tty0.
Loose cabling on the terminal causes line-noise which forces a new getty to be spawned.
The system is keeping track of the total number of gettys spawned for tty0 within a three minute and 45 second period; if that number exceeds five, then an error is displayed on the console and the system shuts down the port.
Note: You can duplicate this yourself by logging in and out of the terminal several times very quickly within the above mentioned time span.
The port will stay in a suspended state for about 19 minutes or until the system administrator "enables" the port again. At the end of the 19 minutes, the system will automatically enable the port.
Note: PTF IX37168 changes the amount of time that the port is suspended from 19 minutes to a maximum of 240 seconds.
------------------------------------------------------------
Causes and suggestions
Modem devices are the most likely causes of the "respawning" error.
Suggestions for HAYES compatible modems:
Connect to the modem and examine the active profile.
Carrier detect should not be forced high ("&C0"
; it should be set for "&C1" with the command AT&C1. In the active profile, verify that "result codes" is either turned off or set to "originate only". Try turning result codes off with "ATQ1".
The "timeout" or "TIME before advancing to next port setting" is set to a value other than 0 for ttys connected directly to terminals.
A port is defined and "enabled" but no cable or device is attached to it.
Suggestions:
"Pdisable" the port and remove the device.
Bad cable or loose connection.
Suggestions:
Verify that the cabling is IBM cabling or that it meets the same standard.
Check for loose connections.
Check for bent pins at the connections.
Replace the cable (as a test) with an IBM serial cable, PN: 6323741.
Corruption/tampering with the /etc/environment or /etc/inittab file.
Suggestions:
If possible, compare these files against known good copies.
Make backup copies of the files and make changes as needed.
In /etc/environment, remove any lines that are not 1) blank lines, 2) comment lines, or 3) variable=<something>.
In /etc/inittab look for strange settings on tty. Sometimes these are customized to fit certain applications (such as the Pic Blue operating system). If the tty is set to off, it is probably not being used and should be checked. Remove any inconsistencies.
Check your error report log with the errpt -a | pg command. Look for errors associated with tty software and/or hardware (e.g. "buffer overruns", "lion_box", or "concentrator" errors).
Suggestions:
If you find hardware errors ("lion_box died", for example), first make sure a user did not cause the error. Then contact your CE (customer engineer). When reporting the problem, mention all errors, including software-related ones.
Note: Certain buffer errors can be caused by faulty hardware.
Noise on communication line.
Suggestions:
Verify that cabling is the correct length and impedance; also check that toroid rings are in place where needed on longer cables.
Check the routing of cables - they should not be close to fluorescent lights, motors, or other high line-noise sources.
Again, verify that cable connections are tight.
TTY configuration is corrupted.
Suggestions:
Try deleting the tty via smit and then re-adding it.
Hardware is defective.
Suggestions:
- Thread starter
- #4
- Status
