Usage: init
Init is the parent of all processes.
This version of init is designed to be run only by the kernel.
BusyBox init doesn't support multiple runlevels. The runlevels field of the /etc/inittab file is completely ignored by BusyBox init. If you want runlevels, use sysvinit.
BusyBox init works just fine without an inittab. If no inittab is found, it has the following default behavior:
::sysinit:/etc/init.d/rcS ::askfirst:/bin/sh |
If it detects that /dev/console is _not_ a serial console, it will also run:
tty2::askfirst:/bin/sh |
If you choose to use an /etc/inittab file, the inittab entry format is as follows:
<id>:<runlevels>:<action>:<process> |
WARNING: This field has a non-traditional meaning for BusyBox init! The id field is used by BusyBox init to specify the controlling tty for the specified process to run on. The contents of this field are appended to "/dev/" and used as-is. There is no need for this field to be unique, although if it isn't you may have strange results. If this field is left blank, the controlling tty is set to the console. Also note that if BusyBox detects that a serial console is in use, then only entries whose controlling tty is either the serial console or /dev/null will be run. BusyBox init does nothing with utmp. We don't need no stinkin' utmp.
Valid actions include: sysinit, respawn, askfirst, wait, once, and ctrlaltdel.
The available actions can be classified into two groups: actions that are run only once, and actions that are re-run when the specified process exits.
Run only-once actions:
'sysinit' is the first item run on boot. init waits until all sysinit actions are completed before continuing. Following the completion of all sysinit actions, all 'wait' actions are run. 'wait' actions, like 'sysinit' actions, cause init to wait until the specified task completes. 'once' actions are asyncronous, therefore, init does not wait for them to complete. 'ctrlaltdel' actions are run immediately before init causes the system to reboot (unmounting filesystems with a 'ctrlaltdel' action is a very good idea).
Run repeatedly actions:
'respawn' actions are run after the 'once' actions. When a process started with a 'respawn' action exits, init automatically restarts it. Unlike sysvinit, BusyBox init does not stop processes from respawning out of control. The 'askfirst' actions acts just like respawn, except that before running the specified process it displays the line "Please press Enter to activate this console." and then waits for the user to press enter before starting the specified process.
Unrecognized actions (like initdefault) will cause init to emit an error message, and then go along with its business. All actions are run in the reverse order from how they appear in /etc/inittab.
# This is run first except when booting in single-user mode. # ::sysinit:/etc/init.d/rcS # /bin/sh invocations on selected ttys # # Start an "askfirst" shell on the console (whatever that may be) ::askfirst:-/bin/sh # Start an "askfirst" shell on /dev/tty2-4 tty2::askfirst:-/bin/sh tty2::askfirst:-/bin/sh tty2::askfirst:-/bin/sh # /sbin/getty invocations for selected ttys # tty4::respawn:/sbin/getty 38400 tty5 tty5::respawn:/sbin/getty 38400 tty6 # Example of how to put a getty on a serial line (for a terminal) # #::respawn:/sbin/getty -L ttyS0 9600 vt100 #::respawn:/sbin/getty -L ttyS1 9600 vt100 # # Example how to put a getty on a modem line. #::respawn:/sbin/getty 57600 ttyS2 # Stuff to do before rebooting ::ctrlaltdel:/bin/umount -a -r ::ctrlaltdel:/sbin/swapoff |