[clue-tech] using screen as init

[Michael J. Hammel]

On Fri, 2006-11-10 at 10:48 -0700, Jim Ockers wrote:
> The curses app has to run fairly early in the boot-up sequence; the mounting
> of non-root filesystems actually could be interrupted or delayed based on
> the error condition, and can only proceed if the error condition is cleared
> (or can't proceed if not cleared).
> 
> I guess I'm not familiar enough with init to know how to make the init
> script that runs the curses app but which runs at the same level & time
> as the rcS sysinit stuff.

Quick overview of init scripts:

The init scripts are run in numerical order (S00blah, S01blah, etc.)
from within their runlevel directories (rcS.d, rc2.d, etc.).  To make a
script run earlier in the boot process, you move it into the earliest
run level and name it with the lowest Sxx value.  The standard way of
doing this is to put your script (sans Sxx prefix) into /etc/rc.d/init.d
and then use chkconfig to create links to the proper runlevel
directories.  In any of the existing init scripts you'll see a comment
like this:

# chkconfig: 2345 90 10

The last two values are used specify the Sxx and Kxx (S for start, K for
kill) positions in the runlevels specified in the first value (2345, in
this case).  The chkconfig tool is used to manage that line and the
symlinks to the runlevel directories.

But then again...

I'd only use inittab to launch an app that didn't try to control the
boot process.  It sounds like you need to do more than just monitor the
boot process.  You need to control of the boot process with the curses
app, which means you probably wouldn't want to use SysV init (ie the
usual init scripts).  Instead, you'd launch a shell script that did
basic config, then launched your screen session.  Basic config would
include making sure the network was running so you could connect to the
screen session remotely and you had a proper console and/or ttys
available.  Your curses app would then drive the rest of the boot
process.

This shell-based scenario is common for embedded systems.  It's also the
basic structure used by initrd (or initramfs) images.

> Could you please suggest a bit more detail about how to accomplish this
> in the way you suggest?

Since the curses app is controlling the boot process, you probably
wouldn't want to use init.  You don't need both init and the curses app
competing for startup processing.  That said, if you wanted to try it,
you'd want to rip out the standard init scripts and replace them with
one script that does the basic config and launches your screen
session/curses app, then you could use inittab to run that script.  Init
could launch multiple config scripts, some for setting up hardware, some
for doing system config, etc.  But it's not much different than having
the script do it for you, and using a simple shell script probably has
less overhead.  

Note that no matter how you do this, screen may not be appropriate for
noting when the curses app has died.  I'm not sure how screen reports a
process has died.  You init scripts or shell script would only be
looking at the screen process status, not it's child.  So screen would
have to provide some feedback or else you couldn't recover from the
death of the curses app.

Anyway, just some thoughts off the top of my head.  :-)
-- 
Michael J. Hammel                                    Senior Software Engineer
mjhammel at graphics-muse.org                           http://graphics-muse.org
------------------------------------------------------------------------------
Never, under any circumstances, take a sleeping pill and a laxative
on the same night. -- Unknown.