init scripts, redhat, console use

[Derek D. Martin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At some point hitherto, bscott at ntisys.com hath spake thusly:
> On Wed, 18 Sep 2002, at 9:39am, shillman at alumni.unh.edu wrote:
> >> I've always just used the "read" built-in for this.
> >
> > Doesn't seem to work with init scripts. 
> 
>   Hmmm.  One of the things Red Hat's initscripts do is run themselves
> through a program called "initlog".  The initlog program captures console
> messages during boot, so it can be logged to syslog.  Which is normally a
> very useful feature.  However, I wonder if it is causing problems with this.

Yup.  The first thing /etc/rc.d/rc.sysinit does is re-run itself
through initlog, with the -r option.  initlog takes all stdout and
stderr from the program, and logs it to syslog -- thus stdout and
stderr aren't (directly) sent to the console.

How it gets there, when it gets there, is unclear to me.  I do note
that all the echo commands have the string preceded by '$'... though I
tried echoing a string with that, and it did nothing.

> > Admittedly, I could probably put the irritating pieces into another script
> > which the first script could call, but I'm trying to avoid that...
> 
>   Try it (or the Perl idea).  I suspect it won't work.  If initlog screwing
> with the terminal is the problem, that will likely be propagated to whatever
> child processes are spawned as well.

For me, reads worked fine, but writes didn't.  In order to get writes
to work, I had to echo them to /dev/console.  YMMV, as different
versions of initlog may decide to redirect different file descriptors.

IOW, I was able to achieve what Suzanne is looking for by simply
doing:

  echo -e "prompt: \c" >/dev/console
  read answer

If this does not work for you, you might try something like this:

  for loop in 1; do
    echo -e "prompt: \c"
    read answer
  done > /dev/console < /dev/console

[The purpose of the loop is simply to prevent having to do the
redirections after each and every command...]

I don't promise either of these will work, but one of them should,
unless your version of initlog is doing something unpleasant...

Incidentally, I almost agree with Kevin's statement about aquiring a
controlling tty.  That is, if steps are taken to prevent the process
from aquiring a controlling tty, it is impossible for it to do so.
However, if those specific required steps are not taken, all that must
be done for the process to re-aquire a controlling tty is to open a
character special file that is a tty...

The steps required to prevent this from working are:

  fork()
  setsid()

So long as this has not been done, you can aquire a controlling tty by
opening any terminal device.  On some systems, a second fork() after
the setsid() may be required to prevent the process from obtaining a
controlling tty.  You can also prevent the process from re-aquiring a
controlling tty by opening any tty devices with the option O_NOCTTY.
But you're not going to do that from a shell script... ;-)  For more,
see Stevens, APitUE ch. 13.  


- -- 
Derek Martin               ddm at pizzashack.org    
- ---------------------------------------------
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9iKaGdjdlQoHP510RAtaGAKCsh1o2R69Tyy2PQ7tVrQzPkSdPvgCfYYnf
XN7sEm5Jz7qzVHr3r8ve8A0=
=uVrI
-----END PGP SIGNATURE-----