Bug 48668 - inittab is not read during bootup & kill -HUP
Summary: inittab is not read during bootup & kill -HUP
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: SysVinit   
(Show other bugs)
Version: 7.1
Hardware: i686 Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-11 06:53 UTC by Aznidin
Modified: 2014-03-17 02:21 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-11 19:11:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Aznidin 2001-07-11 06:53:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
When I first installed (fresh) RH 7.1 directly from CD /etc/inittab was 
read properly.  But when I updated my system from RHN /etc/inittab was not 
read at all during bootup & kill -HUP 1 & init q.  Looks like /etc/rc.d/rc 
works but mingetty does not appear when I do ps auxw.

How reproducible:

Steps to Reproduce:
1. Reboot many times
2. Tried to insert TT:123456:respawn:sleep 60 into /etc/inittab and do 
kill -HUP 1
3. ps auxw

Actual Results:  ps auxw doesn't show any mingetty and new entries 
in /etc/inittab.  To be specific, I need svscan to run for every 
reboot/system startup.

Expected Results:  All default entries in /etc/inittab and newly inserted 
entries should work when reboot & kill -HUP 1 & init q.

Additional info:

# My /etc/inittab file

# System initialization.

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel.

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.  
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon

# Added by Aznidin, Jul 5, 2001
SV:123456:respawn:env - PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin 
svscan /service </dev/null >/dev/console 2>/dev/console
TT:2345:respawn:/bin/sleep 60

Comment 1 Bill Nottingham 2001-07-11 19:11:32 UTC
Is it exactly like above (i.e., is there a newline in the SV entry?)

I can't reproduce this here. Can you post your inittab as an attachment?

Comment 2 Aznidin 2001-07-12 16:45:55 UTC
It's not sysV init bug but I ran a process in rc.local that keep init from 
performing further execution (forgot to append the &).  To be exact, it got 
stuck in /etc/rc 5 command that runs S**local. That's why all the mingetty + 
new inittab entries never execute. I co-locate my server somewhere that I could 
not reach; therefore I could not see the error msg on the console while booting 
that should show some failure point when executing rc.local. dmesg didn't help 
me much.  I figured this out from ps auxw.

Sorry & Thanks anyway.

Note You need to log in before you can comment on or make changes to this bug.