Question about init and controlling TTY

Rob Landley rob at landley.net
Sat Apr 8 02:20:54 UTC 2006


On Friday 07 April 2006 10:01 pm, Devin Bayer wrote:
> Hello.  When I was running some shells on the console recently I kept
> getting the error message:
>
> 	-sh: no job control in this shell
>
> This was even when using getty or the "-" prefix in the inittab.  So
> after
> a little investigating I found that busybox/init/init.c opens the device
> for each command without the O_NOCTTY flag.  The causes the first
> command
> that's run on each terminal to control it.

Even after that command exits?

> In my case I wanted getty to respawn on the console and send output
> from the init
> scripts there.  Since respawning actions happen later then once
> actions, it doesn't seem possible with busybox init.
>
> So I looked at the upstream sysvinit package.  It opens the terminal for
> each command with the O_NOCTTY flag.  I think busybox should do the
> same.
> Here is a patch:
>
> Index: init/init.c
> ===================================================================
> --- init/init.c (revision 14779)
> +++ init/init.c (working copy)
> @@ -430,7 +430,7 @@
>                  setsid();
>
>                  /* Open the new terminal device */
> -               if ((device_open(a->terminal, O_RDWR)) < 0) {
> +               if ((device_open(a->terminal, O_RDWR|O_NOCTTY)) < 0) {
>                          if (stat(a->terminal, &sb) != 0) {
>                                  message(LOG | CONSOLE, "device '%s'
> does not exist.", a->terminal);
>                          } else {

In theory I have no objection since that just means we have a different built 
in constant and should thus be exactly the same size.  (The | is done at 
compile time.)

I'd like to be a little clearer about what you're trying to do though, and 
whether or not this is going to break anybody else who relies on our current 
behavior...

> Note that the "-" prefix for commands in busybox sets that command to
> have the TTY controlling.  So without this patch,
> CONFIG_FEATURE_INIT_SCTTY
> is pretty much useless, since it controls the tty anyway.  Was this
> just an oversight?

Dunno.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list