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

[Tony van der Hoff]

On 8 Jan 2003, in message <a8f6a7b14b.sbrodie at sbrodie.cam.pace.co.uk>,
Stewart Brodie <stewart.brodie at pace.co.uk> wrote:

> 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).
> 
> From what I recall, there was discussion on the mailing list about this
> issue and whether init should be making this ioctl for none, some or all of
> the processes that it forks off.
> 
> > I won't pretend to understand the connection between this system call,
> > the console, and the lack of job control.
> 
> I searched the web for information on progress groups, controlling ttys and
> the like and found one[1] that started off saying something like "Process
> groups are one of the features least well understood by UNIX programmers".  
> I'm not surprised if you read the some of the manual pages like those for
> tcgetattr and getpgrp.  That web page[1] goes on to describe how there are
> different (conflicting) APIs for process group control, which also doesn't
> help when you're trying to understand them.
> 
> I'll try and explain it to the best of my current knowledge (and hope for
> corrections and clarifications from others ;-)
> 
> All processes belong to exactly one process group.  A progress group can
> contain one or more processes.  A progress group is identified by a number
> ("pgid").
> 
> Many process groups may be associated with a single terminal (for example,
> a shell might have several processes running started with "xyz &"
> commands).  However, the terminal will have one process group which is
> deemed to be the foreground process group.  Only processes which are
> members of the foreground process group may perform I/O to the terminal
> device (i.e. through file descriptors which are connected to the terminal
> device).  Non-foreground process groups are signalled with SIGTTIN/SIGTTOU
> if they attempt I/O.
> 
> It is possible to use tcgetpgrp on a file descriptor which is connected to
> a terminal to find out what the current foreground pgid of the terminal is. 
> This can then be compared with the pgid returned by getpgrp to determine
> whether the your process is connected to a terminal AND a member of that
> terminal's current foreground process group.  This is the test that ash
> uses to determine whether or not to permit job control.  It is calling
> tcgetpgrp on stderr's file descriptor and getting back -1/ENOTTY. 
> Presumably that means that a serial console does not identify itself as
> being a TTY then?  
> 
> I'm not sure about any of this - I've been trawling through the kernel
> sources and I'm not sure I haven't confused myself even more now :-)
> 
> 
> 
> [1] http://world.std.com/~jmf/papers/signals/signals.html [2]
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/1285.html
> 

According to [2], that is just about correct. It also introduces the concept
of "login sessions", which contains all the processes that are descendants of
the process that has started a working session on a specific terminal. Each
login session may have several process groups simultaneously active, but only
one process group is in the foreground, which is what you said.

However, as far as I can see, enabling or not of job control should be
independant of whether any process group has access to a terminal; the
concept of a foregound job is not sensible without a terminal, but in
principle, any number of background jobs could be running without.

Therefore, assuming the currently active ash is the current login session,
which may spawn process groups below it, then it is reasonable to assume that
it has access to a terminal - a shell without a terminal is not a lot of use. 
Presumably, if any members of those process groups want to perform terminal
I/O, that is their problem, but is still not relevant to the shell's job
control.

I guess what I'm saying is Why perform the test at all? 

[2] Understanding the Linux Kernel, Bovet & Cesati, O'Reilly, 2001
-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk