[BusyBox 0001244]: (init) inittab handling broken in revision 17937
bugs at busybox.net
bugs at busybox.net
Fri Feb 15 15:21:33 UTC 2008
The following issue has been CLOSED
======================================================================
http://busybox.net/bugs/view.php?id=1244
======================================================================
Reported By: espakman
Assigned To: BusyBox
======================================================================
Project: BusyBox
Issue ID: 1244
Category: Other
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 03-01-2007 13:14 PST
Last Modified: 02-15-2008 07:21 PST
======================================================================
Summary: (init) inittab handling broken in revision 17937
Description:
Since revision 17937 not all items in the inittab are executed.
My inittab file:
::sysinit:/etc/init.d/rcS
::wait:/etc/init.d/rc 2
tty1::respawn:/sbin/getty 38400 tty1
tty2::respawn:/sbin/getty 38400 tty2
::restart:/sbin/init
::shutdown:/etc/init.d/rc 0
The "wait" (rc 2) and "shutdown" (rc 0) scripts are not executed after rev
17937, also if I replace the "wait" with a second "sysinit" this line is
not executed. Running rc 0 or rc 2 by hand or using a busybox before rev
17937 works fine.
Libc: uClibc-0.9.28
gcc: gcc-3.3.3
======================================================================
----------------------------------------------------------------------
espakman - 03-02-07 12:38
----------------------------------------------------------------------
The problem seems to be a bit different. No init startup/shutdown output is
shown on the console anymore and some daemons won't start up on boot time
with this revision (maybe they need a controlling tty?). Some examples of
daemons that won't start on init: dnsmasq and ulogd
----------------------------------------------------------------------
hwstar - 11-24-07 18:45
----------------------------------------------------------------------
I'm seeing a similar issue with Busybox 1.7.2
Inittab does not reliably execute the following lines:
# Startup the system
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -n -o remount,rw /
null::sysinit:/bin/mount -a
null::sysinit:/sbin/ifconfig lo 127.0.0.1 up
null::sysinit:/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
#run the pre init script
::sysinit:/bin/echo "running rc.pre-init"
::sysinit:/etc/init.d/rc.pre-init
::sysinit:/bin/echo "rc.pre-init done"
null::sysinit:/bin/hostname -F /etc/hostname
# now run any rc scripts
::sysinit:/bin/echo "running rcS"
::sysinit:/etc/init.d/rcS
Sometimes rc_pre-init runs, sometimes it doesn't.
Sometimes rcS runs, sometimes it doesn't.
Results vary between boot ups.
----------------------------------------------------------------------
vda - 11-24-07 20:57
----------------------------------------------------------------------
Programs which need controlling tty can be started like this:
::sysinit:/bin/cttyhack <program> <params>
> Sometimes rc_pre-init runs, sometimes it doesn't.
> Sometimes rcS runs, sometimes it doesn't.
What does it print? Does it help when you add /bin/cttyhack as shown
above?
Try disabling FEATURE_INIT_SYSLOG and watching init messages on VT 5.
(Strange method of sending messages, if you ask me).
----------------------------------------------------------------------
hwstar - 11-24-07 22:21
----------------------------------------------------------------------
Ok, I recompiled busybox with cttyhack enabled and FEATURE_INIT_SYSLOG
disabled.
I know of no way to capture the output as I'm using a CRT as the output
device.
VT(5) does show cttyhack is being executed twice with the host name
command in between the two invokations. cttyhack is being executed every
time reliably,
but the shell scripts are not being executed reliably, so maybe there's
nothing wrong with init, and it is a shell issue instead?
Here's the modified inittab snippet:
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -n -o remount,rw /
null::sysinit:/bin/mount -a
null::sysinit:/sbin/ifconfig lo 127.0.0.1 up
null::sysinit:/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
#run the pre init script
::sysinit:/usr/bin/cttyhack /etc/init.d/rc.pre-init
null::sysinit:/bin/hostname -F /etc/hostname
# now run any rc scripts
::sysinit:/usr/bin/cttyhack /etc/init.d/rcS
----------------------------------------------------------------------
vda - 11-24-07 23:57
----------------------------------------------------------------------
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -n -o remount,rw /
null::sysinit:/bin/mount -a
null::sysinit:/sbin/ifconfig lo 127.0.0.1 up
null::sysinit:/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
#run the pre init script
If you add ::sysinit:/bin/sh after above line, you should get a shell
prompt.
Interesting things to try:
echo TEST >/dev/tty - likely will fail, since you have no controlling
tty
ls -l /proc/$$/fd - will show you which descriptors are open
You may run /etc/init.d/rc.pre-init and /etc/init.d/rcS by hand from this
prompt too.
::sysinit:/usr/bin/cttyhack /bin/sh is similar, but controlling tty should
be allocated ("echo TEST >/dev/tty" shall succeed).
Let me know about results of these tests.
----------------------------------------------------------------------
hwstar - 11-25-07 19:58
----------------------------------------------------------------------
With /bin/sh, I do get a shell prompt after the following message:
/bin/sh: can't access tty; job control turned off
Executing echo test > /dev/tty results in the following:
/bin/sh: cannot create /dev/tty: No such device or address
/dev/tty does exist
ls -l /proc/$$/fd shows fd's 0, 1 and 2 linked to /dev/console
rc.pre-init and rcS run just fine from the shell prompt.
both rc.pre-init and rcS do force the use /bin/bash instead of /bin/sh
though.
I find that when I replace /bin/sh with /bin/bash, it sometimes hangs
during invokation. I'm going to change my scripts to use /bin/sh and see
if that makes any difference.
----------------------------------------------------------------------
vda - 11-25-07 20:37
----------------------------------------------------------------------
"can't access tty; job control turned off" is ash's message. I assume
/bin/sh is ash.
"echo test > /dev/tty" error is expected when you don't have a controlling
tty, even if /dev/tty node exists (existence of the node doesn't mean it
can be opened).
> when I replace /bin/sh with /bin/bash, it sometimes hangs during
invokation
This is interesting. specially "sometimes" part. Can you find out why? Can
you do "strace [-f] /bin/bash /script/which/sometimes/fails"? etc...
----------------------------------------------------------------------
hwstar - 11-29-07 21:23
----------------------------------------------------------------------
Changing the scripts to use /bin/sh seems to fix the problem. So its
looking more and more like an issue with bash. I will have to rebuild my
system to have the strace command available to do what you are suggesting.
----------------------------------------------------------------------
vda - 02-15-08 07:21
----------------------------------------------------------------------
No useful feedback from reporter.
Issue History
Date Modified Username Field Change
======================================================================
03-01-07 13:14 espakman New Issue
03-01-07 13:14 espakman Status new => assigned
03-01-07 13:14 espakman Assigned To => BusyBox
03-02-07 12:38 espakman Note Added: 0002196
11-24-07 18:45 hwstar Note Added: 0002955
11-24-07 18:45 hwstar Issue Monitored: hwstar
11-24-07 20:57 vda Note Added: 0002956
11-24-07 20:57 vda Status assigned => feedback
11-24-07 22:21 hwstar Note Added: 0002957
11-24-07 23:57 vda Note Added: 0002958
11-25-07 19:58 hwstar Note Added: 0002960
11-25-07 20:37 vda Note Added: 0002961
11-29-07 21:23 hwstar Note Added: 0002991
02-15-08 07:21 vda Status feedback => closed
02-15-08 07:21 vda Note Added: 0004904
======================================================================
More information about the busybox-cvs
mailing list