|author||Denys Vlasenko <firstname.lastname@example.org>||2010-07-26 11:59:54 (GMT)|
|committer||Denys Vlasenko <email@example.com>||2010-07-26 11:59:54 (GMT)|
FAQ: update "sh: can't access tty; job control turned off" section
Signed-off-by: Denys Vlasenko <firstname.lastname@example.org>
1 files changed, 15 insertions, 2 deletions
@@ -617,13 +617,26 @@ int main(int argc, char *argv)
# 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:
+ # 3. re-execute the shell, allowing it to notice that it has a ctty:
exec setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1'
+ Note that above example talks about <em>interactive shell with PID 1</em>.
+ Thus, it painstakingly uses "exec ..." to keep you in PID 1.
+ If you have "sh: can't access tty" problem when you run interactive shell
+ from, say, an init shell script (IOW: you boot with init=/some/shell/script.sh,
+ and script.sh runs "sh" at some point in order to allow user to type
+ in commands), then execing will be a wrong thing to do. You will need to drop it:
+ setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1'
+ # or using a hack tool:
+ setsid cttyhack sh
If you <em>REALLY</em> 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
+ sort of 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.