[BusyBox] TAKE 2: Message on Startup: "sh: can't access tty; job control turned off"

[Stewart Brodie]

In message <20030107224132.GA16199 at recycle.lbl.gov>
          Larry Doolittle <ldoolitt at recycle.lbl.gov> wrote:

> Guys -
> 
> Vladimir gave an ash patch, then said:
> > But, "job control turned off" problem not solved - previous code
> > have one iteration do while() loop.
> > Current busybox have this problem only for serial console usage   
> > without getty/openvt(real, not bb).
> > Kernel don`t set CTTY automaticaly for open(serail_console).
> 
> This BusyBox init defect appears is new for 0.60.5.
> Reverting to init.c from 0.60.4 fixed it, so I could then
> isolate the problem to a deleted ioctl(0, TIOCSCTTY, 0);
> All the other changes to 0.60.5 are OK.  So try the appended
> patch, it works for me.
[snipped patch that added ioctl(0, TIOCSCTTY, 0); to init.c]

That doesn't work for me with my serial console: I get back -1/EPERM. 

Implicitly, the device_open call just after the setsid() would normally make
the opened device the controlling terminal - which looks to have happened
based on getting EPERM back.  Did you mean to pass 1 as the final parameter
to ioctl?  Putting it in with 1 as the third parameter instead makes the
message go away.  Which is odd, because that implies that there is already a
controlling terminal at the point of that call - yet looking at the tty_open
function in the kernel sources (as detailed in [2]) says that if device major
5/minor 1 (i.e. /dev/console) is being opened, then no controlling terminal
is assigned (well at least I presume that is the point of setting noctty to
1).  Something very odd is going on that I don't understand (yet).