[PATCH] - allow specification of alternate inittab files

Denis Vlasenko vda.linux at googlemail.com
Wed Nov 1 17:55:25 UTC 2006


On Wednesday 01 November 2006 17:35, B Thomas wrote:
> Well, you might think so, and perhaps there is some avenue that I haven't
> explored.  I ended up in situations in which a given inittab just wouldn't
> do the trick and only a different inittab would. For example, what serial
> lines are started and how.  In the end, no amount of scripting seemed to
> help. Only a separate inittab.
> 
> My vague memories of the issue (I solved this some time ago and am only now
> getting around to submitting the change), is that serial lines were a
> prominent pain.  Some systems would start them, others would just error over
> and over and over (the serial line didn't exist, for instance). A lot of
> experimenting with all of the different knobs (boot command options,
> inittab, scripts, etc) ended up with no real answer and only frustration.
> Each system and configuration had its own unique combination of
> requirements. A simple, to the point, change was to simply allow the
> specification of the inittab that you wish to be using.
> 
> A second scenario is, say, for an environment in which you want no serial
> input, but want a debug option. A simple approach is a default inittab with
> no serial lines, and a debug version with serial lines and shells.
> 
> Overall, inittab is a very simple, sane, usable solution.

What is so simple about inittab? Don't forget that you have
dedicated C code in init which needs to handle it, with all that
nasty little quirks about signal handling, controlling ttys,
respawning etc... and I did not even started to mention sysV
runlevel insanity, or that idiotic "reboot by signalling init".

All this can be handled without inittab *at all*. My init
parameter is: init=/init. cat /init:

#!/bin/sh
# Set up env
unset HOSTNAME
unset devfs
unset MACHTYPE
unset SHLVL
unset SHELL
unset HOSTTYPE
unset OSTYPE
unset HOME
unset TERM
export PATH=/bin:/usr/bin
# Open console
exec >/dev/console 2>&1 </dev/null
# Run startup script
/etc/rc.d/start 3
# Close all descriptors
exec >&- 2>&- <&-
# Sleep forever
while true; do env - sleep 32000; done

There you have it. Make /etc/rc.d/start start gettys,
network daemons, serial line daemons, databases etc etc etc.
Use whatever "daemon controller" tool which suits you
(there are several popular ones on the Net).
Kernel's parameters are propagated into /etc/rc.d/start
too (in the environment).

Why bother init task with this mess? It is critical
and harder to debug than "normal" programs, so keep it simple.

Of course I do not plan to throw init out of busybox,
there are too many users of it, but I am sort of reluctant
to _add_ even_ more_ code_ to it. For one, why other
init's out there do not have such thing as alternate inittab?

> This patch very 
> simply allows you a choice to provide some flexibility and builds upon the
> existing mechanism.  As you point out, there are many other choices. This
> was one, low-cost, incredibly simple to implement one that I happened to put
> together.
--
vda



More information about the busybox mailing list