Question about init and controlling TTY

[Devin Bayer]

On Apr 8, 2006, at 13:13, John Z. Bohach wrote:

> On Friday 07 April 2006 20:00, Devin Bayer wrote:
>> 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.
>>
>
> I've tested this patch, and it forces one to have to enable  
> CONFIG_FEATURE_INIT_SCTTY
> in order to maintain backward compatible behavior.  It also forces  
> one to have to
> prefix commands spawned by init with a '-'.  I suspect this is only  
> the case for those
> apps. that do not take care of setting up there own controlling  
> terminal.  I think
> getty does do that, using the console as its CTTY, but I haven't  
> confirmed that.

Yes, that's all correct.  Somewhere along the line FEATURE_INIT_SCTTY  
was added, which is busybox specific behavior.  Then, presumably  
later, all commands were run like that.  The whole point of  
FEATURE_INIT_SCTTY is to set up a controlling terminal for the shell  
without getty.

> All that aside, I can't quite see how it fixed your original  
> problem of not having job
> control enabled in the shell.  I can only presume that's your  
> original problem, because
> if job control is turned off on account of no CTTY, the above is  
> not the error message that
> is produced.  Rather, your error messages means you don't have job  
> control enabled.

Right.  I can't get a controlling TTY if another process already has  
it without stealing it.  And getty doesn't steal it.  The reason this  
works in sysvinit is not all processes get their terminal as a  
controlling terminal so the first one that tries (with or without  
stealing) gets it.

> Other than that, the patch works for me.  I do think that the  
> CONFIG_FEATURE_INIT_SCTTY
> needing to be set should be mentioned in the documentation, and  
> should probably become
> the default if init is enabled and this patch is accepted.

It is mentioned in the help for that configure option.

My patch simply allows standard behavior, with the non-standard  
behavior as an extension.  As opposed to the current situation which  
doesn't allow the standard behavior.

-- 
Devin Bayer