[clue-tech] using screen as init

[Jim Ockers]

Hi CLUEbies,

What do you think about using screen as the kernel's init process, so
that everything (including the real init) runs in a pseudo-tty inside
the screen session?  Then one could log in via telnet or ssh or whatever
and use screen -R to hook into the screen session and see what's going
on on the console.

Obviously the screen session would spawn init inside one of its "screens"
so that init could then start up everything else as usual.

Would this work?  Any pitfalls you can think of?

I'm not sure if I would need to redirect /dev/console to the appropriate
psuedo tty or if that would happen automagically?

We have to do something like this so one can log in and have a look at
a GUI curses app that runs at startup on the console and which requires
user interaction.  Of course the system is headless and has no key-
board, and the only way to talk to it is over the network.

Yes we have tried a serial console and in this environment the serial
cable gets lost a lot.  The lack of the serial console cable is a show
stopper so we have to find a way to get it to work without a serial
cable.  (They do not lose the ethernet cable, or at least have lots
of spares.)

I've also tried using ttysnoops as init and this actually kind
of worked but there were a few crlf translation issues and probably
some other issues.  I like screen because when you attach to a
running screen session it redraws the whole terminal so even if there 
is a big curses app running that doesn't repaint or refresh itself, 
screen will do it for you.

I looked at conserver but it is a terminal server app and the only way
to get this to work with conserver is to have 2 physical serial ports
on the motherboard, connected with a (very short) null modem cable,
and one of them is the initial serial console and the other is the
serial port to which conserver provides access.  Of course this embedded
system has only one serial port and is not upgradeable to have more than
one.

Thanks for your thoughts/ideas and advice.
Jim

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/