[uClinux-dev] shell script hangs inittab
davidm at snapgear.com
Tue Aug 16 06:28:12 EDT 2005
Jivin Andrew Holt lays it down ...
> Is that a special case for uCLinux ? because my understanding of the
> general case is that that fields in inittab are defined as:
> And that action is defined as (see extract from the man page below).
> I notice that the uCLinux inittab entry has one less field which I
> guess is run level (?)
Yep, it's not a special case for uClinux, just a special case for
simpleinit. Simple init runs on linux and uClinux.
simpleinit doesn't do runlevels or any of the fancy stuff, just runs rc
scripts and then respawns processes (with respawn limits),
> The process will be restarted whenever it
> terminates (e.g.
> wait The process will be started once when the specified
> runlevel is
> entered and init will wait for its termination.
> once The process will be executed once when the specified
> runlevel is
> boot The process will be executed during system boot. The
> field is ignored.
> The process will be executed during system boot,
> while init
> waits for its termination (e.g. /etc/rc). The
> runlevels field
> is ignored.
> off This does nothing.
> A process marked with an ondemand runlevel will
> be executed
> whenever the specified ondemand runlevel is called.
> However, no
> runlevel change will occur (ondemand runlevels are ??
> ?????a????????, ???????b????????, and
> An initdefault entry specifies the runlevel which
> should be
> entered after system boot. If none exists, init will
> ask for a
> runlevel on the console. The process field is ignored.
> The process will be executed during system boot. It
> will be exe???????
> cuted before any boot or bootwait entries. The
> runlevels field
> is ignored.
> The process will be executed when the power goes
> down. Init is
> usually informed about this by a process talking to a
> UPS con???????
> nected to the computer. Init will wait for the
> process to fin???????
> ish before continuing.
> As for powerwait, except that init does not wait for
> the pro???????
> cess????????s completion.
> This process will be executed as soon as init is
> that the power has been restored.
> This process will be executed when init is told that
> the battery
> of the external UPS is almost empty and the power
> is failing
> (provided that the external UPS and the monitoring
> process are
> able to detect this condition).
> The process will be executed when init receives the
> SIGINT sig???????
> nal. This means that someone on the system console
> has pressed
> the CTRL???????ALT???????DEL key combination. Typically
> one wants to execute
> some sort of shutdown either to get into
> single???????user level or to
> reboot the machine.
> The process will be executed when init receives a
> signal from
> the keyboard handler that a special key combination
> was pressed
> on the console keyboard.
> The documentation for this function is not complete
> yet; more
> documentation can be found in the kbd???????x.xx
> packages (most recent
> was kbd???????0.94 at the time of this writing).
> Basically you want to
> map some keyboard combination to the
> "KeyboardSignal" action.
> For example, to map Alt???????Uparrow for this purpose
> use the follow???????
> ing in your keymaps file:
> alt keycode 103 = KeyboardSignal
> On 16 Aug 2005, at 00:25, David McCullough wrote:
> >Jivin Andrew Holt lays it down ...
> >>I believe that processes are started by inittab are expected to
> >>exit. if you look at an example from a linux system inittab thus:
> >>ttyS0::respawn:/sbin/getty -p ttyS0 ansi
> >>However I am not sure if uCLinux, without looking harder, support
> >>respawn, however my local uCLinux system has the follwoing inittab:
> >>Both of these programs run as daemons, so return when called.
> >You have the operation of init a little mixed up :-)
> >init runs it commands in the background. If they exit, it will
> >"respawn" them.
> >Commands run from init should not dameonise otherwise init will keep
> >respawning them, since whenever the application it starts exits, it
> >re-runs that application again.
> >David McCullough, davidm at cyberguard.com.au, Custom Embedded
> >Solutions + Security
> >Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://
> >uClinux-dev mailing list
> >uClinux-dev at uclinux.org
> >This message was resent by uclinux-dev at uclinux.org
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> This message was resent by uclinux-dev at uclinux.org
David McCullough, davidm at cyberguard.com.au, Custom Embedded Solutions + Security
Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com
More information about the uClinux-dev