Re: Running a service on a console in the foreground

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Benny Siegert <bsiegert%gmail.com@localhost> writes:

> Hi!
>
> Is it possible to have some program running in the foreground on one of 
> the VTs on startup, instead of getty? I would like it to start up on boot 
> and use the console for input and output. How do you set up such a thing, 
> or is this simply not supported?


There are a few considerations, but ya, it should be possible.

One method would be to disable getty on the tty you want to use, or
allocate another one and then put into something like /etc/rc.local
"program < /dev/ttyEx > /dev/ttyEx 2>&1 &" and see how that works for
you.  This can be tested without messing with /etc/rc.local by disable
getty and then just trying to start the program in another shell (on
another virtual console or otherwise).  The problems here may be the
ownership of the /dev/ttyEx device (x being whatever virtual console
number you used) and the general lack of tty set up.  You may be able to
solve some of this with ownership changes on the /dev/ttyEx device and
hopefully your program sets the tty up completely on its own.

If you can tolerate some interaction you can make getty use something
other than login as the login program.  On my DOM0 systems I have this
in my /etc/ttys:

ttyE3   "/usr/libexec/getty Pcsh"       wsvt25  on  secure

and then this in /etc/gettytab:

Pcsh|Pcsh console:\
        :np:ig:ht:lo=/etc/run_shx:

and then this in /etc/run_shx as a executable shell script:

#!/bin/sh

if [ -f "/rescue/csh" ]
then
    exec /rescue/csh -l
else
    echo "Missing /rescue/csh"
    exit 1
fi


In this case /dev/ttyE3 will present a username prompt, but anything
entered will work and it will drop you into a csh shell.  The reason to
do all of this, as opposed to just starting /rescue/csh directly, is
that getty sets up the /dev/tty device a bit, so things like job control
and the like work as expected.  You may not need this set up if you are
not trying to run a shell (I ended up using csh mostly because it just
worked, sh and ksh still didn't like the arrangement).  The effect is to
give me the ability to log into the console of the DOM0 without a
password, and have a workable set up to fix something if the normal
username / password stuff won't let me in as expected (i.e. maybe
kerberos is unavailable or ldap, or something.. or whatever...).






-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org