Question about init and controlling TTY

[John Z. Bohach]

On Saturday 08 April 2006 16:38, Devin Bayer wrote:
> >
> > 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.

Yes, the current behavior (sans patch) is quite contradictory.

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

Runs this by me again...its been a while since I've perused the Richard Stevens
APUE book.  Session leaders get the CTTY.  Sometimes by default sometimes
not, depending on implementation.  I don't know how Linux implemented it.  Regardless,
child processes inherit the CTTY of the session leader, as long as they're in the
foreground process group.  Background process groups close the CTTY, as one of
the prereqs. to going to the background, no?  Thus bg procs. have no CTTY, and if one
does try to access stdin/stdout, strange things happen.  Daemons, by definition, have no
CTTY.   Anyway, I digress...

So you're saying that an fd can only be opened once, then subsequent opens
must supply a | O_NOCTTY flag, else the subsequent openers 'steal' the CTTY? 
Could you clarify what you mean?

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

Yeah, that's about my conclusion too.  However, there's a lot of history with
the non-standard behavior.  Accepting this patch will definitely cause people to
have to change init scripts in the current rootfs they're using with busybox, even
if they remember to enable the CONFIG_FEATURE_INIT_SCTTY option.

I'm all in favor of standardization, but not breaking past behavior would be nice too...

Someone else can flip this coin...jugding by the lack of a great outcry against it,
maybe the patch should be accepted.  On the other hand, we won't know the full
impact in the field until after that, so depending on feedback afterwards, it may have
to get pulled.  Just my 2¢.