problems with /dev/console and "job control"

[Denys Vlasenko]

On Sunday 27 June 2010 00:40, Christian Ruppert wrote:
> >>>>>>>> I try to setup busybox properly for my initrd although I don't get it
> >>>>>>>> working with "job control".
> >>>>>>>> I thought that console=... would help (kernel cmdline) but it doesn't.
> >>>>>>>>
> >>>>>>>> It works so far (at least CTRL+C) if I use openvt -s but that is no
> >>>>>>>> solution for me.
> >>>>>>>> I use my own /init script which later calls "exec /bin/sh" to enter a
> >>>>>>>> rescue shell but CTRL+C etc. isn't working. :(
> >>>>>>>
> >>>>>>> Does this answer your question?
> >>>>>>>
> >>>>>>> http://busybox.net/FAQ.html#job_control
> >>>>>>
> >>>>>> Not really because how can I run the shell in a real console there?
> >>>>>> I have no ttySX at all and other console= values doesn't seem to work.
> >>>>>
> >>>>> So you do not know what is your tty?
> >>>> I do.. I'll rephrase it:
> >>>> I don't have a serial cable connected or anything else so I can't test
> >>>> different console= parameter.
> >>>
> >>> No one said that you need to.
> >>>
> >>> http://busybox.net/FAQ.html#job_control says:
> >>>
> >>> "Your should run your shell on a normal tty such as tty1 or ttyS0 and everything
> >>> will work perfectly".
> >>>
> >>> It does not say "set your console= kernel parameter to tty1 or ttyS0".
> >>>
> >>> Please try running "sh </dev/tty1 >/dev/tty1 2>/dev/tty1"
> >>
> >> Still the same...
> >> "sh: can't access tty; job control turned off"
> > 
> > Ok, now try
> > 
> > setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>/dev/tty1'
> 
> That works, thanks! :)
> One should add it to the FAQ :P

Updated:


Why do I keep getting "sh: can't access tty; job control turned off" errors?
Why doesn't Control-C work within my shell?

Job control will be turned off since your shell can not obtain a controlling
terminal. This typically happens when you run your shell on /dev/console.
The kernel will not provide a controlling terminal on the /dev/console
device. Your should run your shell on a normal tty such as tty1 or ttyS0 and
everything will work.

Example: you booted into your machine with init=/bin/sh and got "sh: can't
access tty" error because sh has its stdio opened to /dev/console. You want
to reopen stdio to, say, /dev/tty1 and thus acquire a controlling tty.

    # Let's try this:
    exec </dev/tty1 >/dev/tty1 2>&1
    # No, doesn't work: even if opening /dev/tty1 gave sh the ctty,
    # sh wouldn't know it - it checks for ctty just once at startup.

    # Let's try re-execing sh:
    exec </dev/tty1 >/dev/tty1 2>&1
    exec sh
    # Got "sh: can't access tty" again. Why?
    # The reason is somewhat obscure: kernel starts process with PID=1
    # (in this case, shell) with SID=0 and PGID=0, not with SID=1 and PGID=1
    # as you'd expect. IOW: our sh is not a session leader, and therefore
    # cannot acquire ctty by opening /dev/tty1 (or any other tty).

    # Let's try making us a session leader:
    exec setsid sh
    exec </dev/tty1 >/dev/tty1 2>&1
    exec sh
    # Yes, this worked!

    # This can be combined into one command,
    # but need to be careful and perform these operations
    # in the correct order:
    # 1. make ourself session leader,
    # 2. open /dev/tty1 and thus acquire a ctty,
    # 3. re-execute the shell, allowing it to notice that it has ctty:
    exec setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1'

If you REALLY want your shell to run on /dev/console, then you can hack your
kernel (if you are into that sortof thing) by changing drivers/char/tty_io.c
to change the lines where it sets "noctty = 1;" to instead set it to "0". I
recommend you instead run your shell on a real console.


-- 
vda