This is the strangest thing I have seen. We have a customer site that
when you log out of the system, the getty does not respawn.
It is running init level 2 (which I checked by doing a who -r), and
the /etc/inittab entry has the getty entry's set for respawn set at 2.
When you log in and then
exit out, /etc/init does not respawn getty. I do a init q and still
the getty does not respawn. I then re-check the /etc/inittab and
the entry is still set for respawn at level 2. The on-site tech says that
there are no messages on the console (like respawning too rapidly or
anything). The only way to get the gettys back is to re-boot. I checked
the inittab to look for anything strange like duplicate getty entries
for the same tty (also made sure that only the non-modem control entries
were enabled), or entries with the same 1st field, but I didn't
see anything out of the ordinary. This appears to
be happening on all tty's (console and Digiboard ports).
When I do a ps -ef I notice that /etc/init is using an enormous
amount of cpu time (when doing 2 ps -ef's about 10 seconds apart, init
has used up about 4 seconds of CPU time).
A ps -ef command shows values in the range of 40-80 in the C field which
is normally 0 on a system that runs with no problems (ps -ef C field has
something to do with CPU usage). I thought there might
be something in /etc/inittab that was causing /etc/init to try and
respawn something over and over, so I do a ps and the process id of
ps is 1203, then 10 seconds later do another ps and the pid of the
2nd ps is 1204, so /etc/init must not be respawning anything over and
over (or at least successfully respawning anything).
I ran crash and the only file open by /etc/init is /etc/utmp, so
I thought maybe /etc/utmp might be so large that /etc/init was
spending all of its time reading/writing /etc/utmp, but it is less
than 2K (and so is /etc/wtmp).
What could /etc/init be doing that is causing it to use up a
tremendous amount of CPU time?