/etc/init does not respawn getty

/etc/init does not respawn getty

Post by Don Lee - Sr. Software En » Thu, 03 Aug 1995 04:00:00



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?

HELP,

Don

 
 
 

/etc/init does not respawn getty

Post by Lawrence Kirb » Fri, 04 Aug 1995 04:00:00




Quote:>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).

Well, clearly there is something up with the init process. Most likely
there is something wrong with one of the files it is accessing. man init
provides a list of files. /etc/inittab is most likely, /etc/initscript
is a possibility (do you just see one init process in the ps list?)

Another possibility is that a kernel resource is exhausted

Quote:>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).

who -a might show up something fishy in /etc/utmp.

Quote:>What could /etc/init be doing that is causing it to use up a
>tremendous amount of CPU time?

Use something like sar to see if it is mainly user or system time. The
system call rate, read() rate and write() rate might also give some clues.

Are you getting a lot of zombie processes left around? It is up to init
clear up orphaned processes.

--
-----------------------------------------


-----------------------------------------

 
 
 

1. Init & getty respawn too fast

For some reason getty respawns too fast, thus being caught by Init and
disabled for 5 minutes. Here's what the /var/log/daemon.log looks like:

  Feb  9 15:25:09 host init: Id "1" respawning too fast: disabled for 5 minutes
  Feb  9 15:37:27 host init: Id "1" respawning too fast: disabled for 5 minutes
  Feb  9 15:49:46 host init: Id "1" respawning too fast: disabled for 5 minutes

And here is a portion of my inittab file:

  # /sbin/getty invocations for the runlevels.
  #
  # The "id" field MUST be the same as the last
  # characters of the device (after "tty").
  #
  # Format:
  #  <id>:<runlevels>:<action>:<process>
  1:2345:respawn:/sbin/getty 9600 tty1
  2:23:respawn:/sbin/getty 9600 tty2
  # 3:23:respawn:/sbin/getty 9600 tty3
  # 4:23:respawn:/sbin/getty 9600 tty4
  # 5:23:respawn:/sbin/getty 9600 tty5
  # 6:23:respawn:/sbin/getty 9600 tty6

I had this problem earlier, but then it disappeared. It just appeared
again a few days ago, without any apparent cause, and has now disappeared.
The weird thing is that I don't ever touch the console--there isn't even a
monitor hooked up to the box! (Although there is a keyboard, just in
case.) Thus the reason I only have two getty's running for those rare
occasions when I plug in a monitor and need to look at something.

The box is a 586/133 running Debian 1.2 with kernel 2.0.27 (it appeared
earlier running Debian 1.1 with kernel 2.0.6).

Any clues why this might happen?

 //  Have a Coke and a Smile!     home to The Choir and Coca-Cola \\
||  http://www.cen.uiuc.edu/~mr-gates/   (choir.html or coke.html) ||

2. Looking for a Linux Fortran compiler/development environment

3. /etc/init.d/acct vs /etc/init.d/perf

4. Remote backup

5. Getty not respawning on logout

6. Source Code for "cal"

7. Getty not respawning reliably on ttyS2

8. Does mksysb backup all the file systems in rootvg?

9. : Getty not respawning properly

10. init: can't exec getty '/usr/libexec/getty' for port /dev/ttyv0:

11. /etc/getty and /etc/inittab woes

12. please email me a copy of your init.d file (/etc/init.d)

13. getty won't always respawn...HELP!