problems with /dev/console and "job control"

Christian Ruppert idl0r at
Sun Jun 27 08:42:07 UTC 2010

On 06/27/2010 02:34 AM, Denys Vlasenko wrote:
> 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?
>>>>>>>> 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.
>>>>> 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.

Thanks! :)

Christian Ruppert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the busybox mailing list