Question about init and controlling TTY

Devin Bayer devin at freeshell.org
Sat Apr 8 03:00:45 UTC 2006


On Apr 7, 2006, at 19:20, Rob Landley wrote:
> 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?

No.  But I like to have the login prompt come up before the init  
scripts finish.  It's an issue whenever two programs are running from  
init on the same tty, for example when running daemons in the  
foreground with init respawn options.

>
>> 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...

It should still be changed.  It's currently not possible to have a  
setup that would be normal for the sysvinit package.  The  
FEATURE_INIT_SCTTY option is a busybox specific thing that is enabled  
when the first character of the command is a dash.  But for some  
reason that behavior was applied to every command.  If you look at  
the code and the documentation for FEATURE_INIT_SCTTY you'll see the  
busybox init does exactly what the docs say isn't normal behavior.

-- 
Devin Bayer




More information about the busybox mailing list