Re: Booting into /bin/bash
On Fri, 15 Sep 2000, Russell King wrote:
> There are two ways for a tty to become a controlling terminal:
>
> 1. First tty opened after a successful setsid() call.
> 2. using the TIOCSCTTY ioctl after a successful setsid() call.
>
> Both will only suceed if the current process does not already have a
> controlling terminal.
>
> (Note that TIOCSCTTY takes an argument which means "steal the controlling
> tty from another session leader, if any" which only works if the calling
> process is UID0).
>
There was an argument, but strace didn't show it.
> Therefore...
>
> Richard B. Johnson writes:
> > setsid()= 6
> > open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
>
> at this point, tty1 is your controlling terminal (by condition 1 above),
> and
>
There is no controlling terminal, ^C doesn't work, etc. even though
the terminal parameters are properly set ISIG|ICANNON|ETC.
> > fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
> > fcntl(3, F_SETFL, O_RDWR) = 0
> > dup2(3, 0) = 0
> > dup2(3, 1) = 1
> > dup2(3, 2) = 2
> > ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
>
> fails because you already have a controlling terminal.
>
> Read:
> drivers/char/tty_io.c:tiocsctty
> drivers/char/tty_io.c:tty_open
> kernel/sys.c:sys_setsid
>
I have read these and I think I have found a long-standing bug.
The 'rules' you cite seem to work if there is an initial fork().
However, they certainly don't work with PID=1.
I got it to work as:
int main()
{
int stat, i, flags, fd;
sigset_t sig;
struct termios term;
struct sigaction sa;
i = 0;
[SNIPPED...]
(void)sigemptyset();
(void)sigprocmask(SIG_SETMASK, , NULL);
memset(, 0x00, sizeof(sa));
sa.sa_handler = reaper;
sa.sa_flags = SA_RESTART;
(void)sigaction(SIGCHLD, , NULL);
sa.sa_handler = stopper;
(void)sigaction(SIGTSTP, , NULL);
sa.sa_handler = starter;
(void)sigaction(SIGCONT, , NULL);
sa.sa_handler = SIG_IGN;
(void)sigaction(SIGINT, , NULL);
memset(, 0x00, sizeof(term));
term.c_cc[VINTR] = (char) 'C' - 64;
term.c_cc[VQUIT] = (char) '' - 64;
term.c_cc[VKILL] = (char) 'U' - 64;
term.c_cc[VEOF] = (char) 'D' - 64;
term.c_cc[VSTART] = (char) 'Q' - 64;
term.c_cc[VSTOP] = (char) 'S' - 64;
term.c_cc[VSUSP] = (char) 'Z' - 64;
term.c_cc[VERASE] = (char) 127;
term.c_cc[VTIME] = (char) 0;
term.c_cc[VMIN] = (char) 1;
term.c_oflag = OPOST|ONLCR;
term.c_iflag = ICRNL|IXON;
term.c_lflag = ISIG|ICANON|ECHO|ECHOE|ECHOK|ECHOKE;
term.c_cflag = B9600|CS8|CREAD|HUPCL|CLOCAL;
(void)tcsetattr(0, TCSANOW, );
for(;;) {
switch(fork()) {
case 0:
(void)ioctl(0, TIOCNOTTY, 0);
(void)close(0);
(void)close(1);
(void)close(2);
(void)setsid();
(void)open("/dev/tty1", O_RDWR|O_NDELAY,0);
flags = fcntl(0, F_GETFL, 0);
flags &= ~O_NDELAY;
(void)fcntl(0, F_SETFL, flags);
(void)dup(0);
(void)dup(0);
(void)tcsetattr(0, TCSANOW, );
if(ioctl(0, TIOCSCTTY, 1)<0)
perror("ioctl(TIOCSCTTY)");
i = 0;
sa.sa_handler = SIG_DFL;
for(i=1; i< NSIG; i++)
(void)sigaction(i, , NULL);
sa.sa_handler = reaper;
(void)sigaction(SIGCHLD, , NULL);
(void)execve(argv[0], argv, environ);
perror("execve");
exit(1);
case -1:
fprintf(stderr, "Fork failed\n");
break;
default:
(void)wait();
}
(void)sleep(1);
(void)tcsetattr(0, TCSANOW, );
(void)write(0, fixscr, sizeof(fixscr) -1 );
}
}
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Thu, 14 Sep 2000, Ion Badulescu wrote:
> On Fri, 15 Sep 2000, Russell King wrote:
>
> > There are two ways for a tty to become a controlling terminal:
> >
> > 1. First tty opened after a successful setsid() call.
> > 2. using the TIOCSCTTY ioctl after a successful setsid() call.
> >
> > Both will only suceed if the current process does not already have a
> > controlling terminal.
>
> Both will fail for pid=1, which does not already have a controlling
> terminal.
>
> > Therefore...
> >
> > Richard B. Johnson writes:
> > > setsid()= 6
> > > open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
>
> Look at his setsid() result. It is 6, so it was called from pid=6. Trust
> me, it DOES NOT WORK for pid=1.
>
> Adding a setsid() call at the very beginning of init() in init/main.c
> makes pid=1 a process leader, at a time when it's still possible (no other
> threads are running). After that, another kernel change can give it
> /dev/console as its controlling terminal, or it can acquire the
> controlling terminal itself via ioctl(0, TIOCSCTTY, 1).
>
The __only__ way I have found to get a controlling terminal is to
fork() first. Then all the 'rules' seem to work. However, it is
not all that clean because:
(1) The first ioctl(TIOCNOTTY) returns -1 with errno set to EINVAL.
However, without this call, I can't get a controlling terminal later.
(2) The first open() after setsid() does not automatically make it
a controlling terminal.
(3) Without the initial fork() nothing works in a logical way.
switch(fork()) {
case 0:
(void)ioctl(0, TIOCNOTTY, 0);
(void)close(0);
(void)close(1);
(void)close(2);
(void)setsid();
(void)open("/dev/tty1", O_RDWR|O_NDELAY,0);
flags = fcntl(0, F_GETFL, 0);
flags &= ~O_NDELAY;
(void)fcntl(0, F_SETFL, flags);
(void)dup(0);
(void)dup(0);
(void)tcsetattr(0, TCSANOW, );
if(ioctl(0, TIOCSCTTY, 1)<0)
perror("ioctl(TIOCSCTTY)");
i = 0;
sa.sa_handler = SIG_DFL;
for(i=1; i< NSIG; i++)
(void)sigaction(i, , NULL);
sa.sa_handler = reaper;
(void)sigaction(SIGCHLD, , NULL);
(void)execve(argv[0], argv, environ);
perror("execve");
exit(1);
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Thu, 14 Sep 2000, Ion Badulescu wrote:
On Fri, 15 Sep 2000, Russell King wrote:
There are two ways for a tty to become a controlling terminal:
1. First tty opened after a successful setsid() call.
2. using the TIOCSCTTY ioctl after a successful setsid() call.
Both will only suceed if the current process does not already have a
controlling terminal.
Both will fail for pid=1, which does not already have a controlling
terminal.
Therefore...
Richard B. Johnson writes:
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
Look at his setsid() result. It is 6, so it was called from pid=6. Trust
me, it DOES NOT WORK for pid=1.
Adding a setsid() call at the very beginning of init() in init/main.c
makes pid=1 a process leader, at a time when it's still possible (no other
threads are running). After that, another kernel change can give it
/dev/console as its controlling terminal, or it can acquire the
controlling terminal itself via ioctl(0, TIOCSCTTY, 1).
The __only__ way I have found to get a controlling terminal is to
fork() first. Then all the 'rules' seem to work. However, it is
not all that clean because:
(1) The first ioctl(TIOCNOTTY) returns -1 with errno set to EINVAL.
However, without this call, I can't get a controlling terminal later.
(2) The first open() after setsid() does not automatically make it
a controlling terminal.
(3) Without the initial fork() nothing works in a logical way.
switch(fork()) {
case 0:
(void)ioctl(0, TIOCNOTTY, 0);
(void)close(0);
(void)close(1);
(void)close(2);
(void)setsid();
(void)open("/dev/tty1", O_RDWR|O_NDELAY,0);
flags = fcntl(0, F_GETFL, 0);
flags = ~O_NDELAY;
(void)fcntl(0, F_SETFL, flags);
(void)dup(0);
(void)dup(0);
(void)tcsetattr(0, TCSANOW, term);
if(ioctl(0, TIOCSCTTY, 1)0)
perror("ioctl(TIOCSCTTY)");
i = 0;
sa.sa_handler = SIG_DFL;
for(i=1; i NSIG; i++)
(void)sigaction(i, sa, NULL);
sa.sa_handler = reaper;
(void)sigaction(SIGCHLD, sa, NULL);
(void)execve(argv[0], argv, environ);
perror("execve");
exit(1);
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Fri, 15 Sep 2000, Russell King wrote:
There are two ways for a tty to become a controlling terminal:
1. First tty opened after a successful setsid() call.
2. using the TIOCSCTTY ioctl after a successful setsid() call.
Both will only suceed if the current process does not already have a
controlling terminal.
(Note that TIOCSCTTY takes an argument which means "steal the controlling
tty from another session leader, if any" which only works if the calling
process is UID0).
There was an argument, but strace didn't show it.
Therefore...
Richard B. Johnson writes:
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
at this point, tty1 is your controlling terminal (by condition 1 above),
and
There is no controlling terminal, ^C doesn't work, etc. even though
the terminal parameters are properly set ISIG|ICANNON|ETC.
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
fails because you already have a controlling terminal.
Read:
drivers/char/tty_io.c:tiocsctty
drivers/char/tty_io.c:tty_open
kernel/sys.c:sys_setsid
I have read these and I think I have found a long-standing bug.
The 'rules' you cite seem to work if there is an initial fork().
However, they certainly don't work with PID=1.
I got it to work as:
int main()
{
int stat, i, flags, fd;
sigset_t sig;
struct termios term;
struct sigaction sa;
i = 0;
[SNIPPED...]
(void)sigemptyset(sig);
(void)sigprocmask(SIG_SETMASK, sig, NULL);
memset(sa, 0x00, sizeof(sa));
sa.sa_handler = reaper;
sa.sa_flags = SA_RESTART;
(void)sigaction(SIGCHLD, sa, NULL);
sa.sa_handler = stopper;
(void)sigaction(SIGTSTP, sa, NULL);
sa.sa_handler = starter;
(void)sigaction(SIGCONT, sa, NULL);
sa.sa_handler = SIG_IGN;
(void)sigaction(SIGINT, sa, NULL);
memset(term, 0x00, sizeof(term));
term.c_cc[VINTR] = (char) 'C' - 64;
term.c_cc[VQUIT] = (char) '' - 64;
term.c_cc[VKILL] = (char) 'U' - 64;
term.c_cc[VEOF] = (char) 'D' - 64;
term.c_cc[VSTART] = (char) 'Q' - 64;
term.c_cc[VSTOP] = (char) 'S' - 64;
term.c_cc[VSUSP] = (char) 'Z' - 64;
term.c_cc[VERASE] = (char) 127;
term.c_cc[VTIME] = (char) 0;
term.c_cc[VMIN] = (char) 1;
term.c_oflag = OPOST|ONLCR;
term.c_iflag = ICRNL|IXON;
term.c_lflag = ISIG|ICANON|ECHO|ECHOE|ECHOK|ECHOKE;
term.c_cflag = B9600|CS8|CREAD|HUPCL|CLOCAL;
(void)tcsetattr(0, TCSANOW, term);
for(;;) {
switch(fork()) {
case 0:
(void)ioctl(0, TIOCNOTTY, 0);
(void)close(0);
(void)close(1);
(void)close(2);
(void)setsid();
(void)open("/dev/tty1", O_RDWR|O_NDELAY,0);
flags = fcntl(0, F_GETFL, 0);
flags = ~O_NDELAY;
(void)fcntl(0, F_SETFL, flags);
(void)dup(0);
(void)dup(0);
(void)tcsetattr(0, TCSANOW, term);
if(ioctl(0, TIOCSCTTY, 1)0)
perror("ioctl(TIOCSCTTY)");
i = 0;
sa.sa_handler = SIG_DFL;
for(i=1; i NSIG; i++)
(void)sigaction(i, sa, NULL);
sa.sa_handler = reaper;
(void)sigaction(SIGCHLD, sa, NULL);
(void)execve(argv[0], argv, environ);
perror("execve");
exit(1);
case -1:
fprintf(stderr, "Fork failed\n");
break;
default:
(void)wait(stat);
}
(void)sleep(1);
(void)tcsetattr(0, TCSANOW, term);
(void)write(0, fixscr, sizeof(fixscr) -1 );
}
}
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Fri, 15 Sep 2000, Russell King wrote:
> There are two ways for a tty to become a controlling terminal:
>
> 1. First tty opened after a successful setsid() call.
> 2. using the TIOCSCTTY ioctl after a successful setsid() call.
>
> Both will only suceed if the current process does not already have a
> controlling terminal.
Both will fail for pid=1, which does not already have a controlling
terminal.
> Therefore...
>
> Richard B. Johnson writes:
> > setsid()= 6
> > open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
Look at his setsid() result. It is 6, so it was called from pid=6. Trust
me, it DOES NOT WORK for pid=1.
Adding a setsid() call at the very beginning of init() in init/main.c
makes pid=1 a process leader, at a time when it's still possible (no other
threads are running). After that, another kernel change can give it
/dev/console as its controlling terminal, or it can acquire the
controlling terminal itself via ioctl(0, TIOCSCTTY, 1).
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
There are two ways for a tty to become a controlling terminal:
1. First tty opened after a successful setsid() call.
2. using the TIOCSCTTY ioctl after a successful setsid() call.
Both will only suceed if the current process does not already have a
controlling terminal.
(Note that TIOCSCTTY takes an argument which means "steal the controlling
tty from another session leader, if any" which only works if the calling
process is UID0).
Therefore...
Richard B. Johnson writes:
> setsid()= 6
> open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
at this point, tty1 is your controlling terminal (by condition 1 above),
and
> fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
> fcntl(3, F_SETFL, O_RDWR) = 0
> dup2(3, 0) = 0
> dup2(3, 1) = 1
> dup2(3, 2) = 2
> ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
fails because you already have a controlling terminal.
Read:
drivers/char/tty_io.c:tiocsctty
drivers/char/tty_io.c:tty_open
kernel/sys.c:sys_setsid
for more information and enlightenment.
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
There are two ways for a tty to become a controlling terminal:
1. First tty opened after a successful setsid() call.
2. using the TIOCSCTTY ioctl after a successful setsid() call.
Both will only suceed if the current process does not already have a
controlling terminal.
(Note that TIOCSCTTY takes an argument which means "steal the controlling
tty from another session leader, if any" which only works if the calling
process is UID0).
Therefore...
Richard B. Johnson writes:
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
at this point, tty1 is your controlling terminal (by condition 1 above),
and
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
fails because you already have a controlling terminal.
Read:
drivers/char/tty_io.c:tiocsctty
drivers/char/tty_io.c:tty_open
kernel/sys.c:sys_setsid
for more information and enlightenment.
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Fri, 15 Sep 2000, Russell King wrote:
There are two ways for a tty to become a controlling terminal:
1. First tty opened after a successful setsid() call.
2. using the TIOCSCTTY ioctl after a successful setsid() call.
Both will only suceed if the current process does not already have a
controlling terminal.
Both will fail for pid=1, which does not already have a controlling
terminal.
Therefore...
Richard B. Johnson writes:
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
Look at his setsid() result. It is 6, so it was called from pid=6. Trust
me, it DOES NOT WORK for pid=1.
Adding a setsid() call at the very beginning of init() in init/main.c
makes pid=1 a process leader, at a time when it's still possible (no other
threads are running). After that, another kernel change can give it
/dev/console as its controlling terminal, or it can acquire the
controlling terminal itself via ioctl(0, TIOCSCTTY, 1).
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote: > Stick a setsid() before the tty stuff. Have you tried it? There is a good reason why I put the setsid() call so early in kernel's init(). Once the initialization is done, init will have several kernel threads as part of its process group, even though it's not a process leader itself... Yeah, inconsistent, but enough to make setsid() fail. At the very very least, the part of my patch that adds the setsid() call should be applied, so process number 1 _can_ acquire a controlling tty if it wants to. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Richard B. Johnson:
> I'm checking on it now. Here's a strace with setsid() ahead, same
> problem:
Yes, sessions, process groups, and controlling ttys are weird
and hard to understand. And probably braindamaged as well, if
not, it's what they cause anyway ;)
If you want to forcibly get a controlling tty:
/* Make sure we do not have a controlling tty. */
ioctl(0, TIOCNOTTY, 0);
close(0);
close(1);
close(2);
/* Become session leader */
setsid();
/* Open tty which will become new controlling tty. */
open("/dev/tty1", O_RDWR);
dup(0);
dup(0);
/* Just to be sure, force controlling tty, in case /dev/tty1
was the ctty for another process. Only root may do this! */
ioctl(0, TIOCSCTTY, 1);
Mike.
--
Deadlock, n.:
Deceased rastaman.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote:
> According to Richard B. Johnson:
> > Without patching the kernel, I think I can show that there is something
> > basically wrong. The patch may just hide the problem.
>
> No.
Try it.
>
> > Something seems to be wrong, even with using the first virtual
> > terminal, which is a 'tty' and should (must) be able to become a
> > a controlling terminal.
>
> Only if you're the process group leader.. read drivers/char/tty_io.c
> function tiocsctty()
>
> And that is the cause of you not being process group leader.
> Stick a setsid() before the tty stuff.
>
> Mike.
Well 'init' was supposed to be the process group leader by default.
however, here is a trace with setsid() just to "make sure".
brk(0) = 0x8049fdc
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)= 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)= 0
mmap(0, 644232, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4000c000
mprotect(0x40097000, 74888, PROT_NONE) = 0
mmap(0x40097000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8b000) =
0x40097000
mmap(0x4009d000, 50312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|0x20, 4294967295,
0) = 0x4009d000
close(3)= 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_WRITE) = 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_EXEC) = 0
SYS_136(0, 0x1, 0x4009c02c, 0xb77c, 0xb774) = 0
getpid()= 6
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
brk(0) = 0x8049fdc
brk(0x804a02c) = 0x804a02c
brk(0x804b000) = 0x804b000
I think I remember, that there was a discussion several years ago that
"The first N processes are supposed to be special" so there may
be something bogus keeping them from having a controlling terminal.
Like they may be "marked" as having a controlling terminal, but they
don't really have one. This would cause tiocsctty() to return -EPERM
(line 1553 in tty_io.c).
I will make another experiment and attempt to release any 'controlling
terminal' before I make the call again.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Wed, 13 Sep 2000, David S. Miller wrote:
>Date: Wed, 13 Sep 2000 09:25:28 -0400 (EDT)
>From: "Richard B. Johnson" <[EMAIL PROTECTED]>
>
>I haven't a clue why a UID/GID=0 process can't acquire a
>controlling TTY.
>
> It probably is some bogosity to do with process groups
> of the init kernel thread which execve's init.
>
> Later,
> David S. Miller
> [EMAIL PROTECTED]
> -
I'm checking on it now. Here's a strace with setsid() ahead, same
problem:
close(3)= 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_WRITE) = 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_EXEC) = 0
SYS_136(0, 0x1, 0x4009c02c, 0xb77c, 0xb774) = 0
getpid()= 6
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
brk(0) = 0x8049fdc
brk(0x804a02c) = 0x804a02c
brk(0x804b000) = 0x804b000
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Richard B. Johnson: > Without patching the kernel, I think I can show that there is something > basically wrong. The patch may just hide the problem. No. > Something seems to be wrong, even with using the first virtual > terminal, which is a 'tty' and should (must) be able to become a > a controlling terminal. Only if you're the process group leader.. read drivers/char/tty_io.c function tiocsctty() > This is a stock kernel version 2.2.15. The stuff necessary to make > 'strace' run ends up with the 'init' PID of 6. FYI, it is a real > bear to 'strace' init's startup. And that is the cause of you not being process group leader. Stick a setsid() before the tty stuff. Mike. -- Deadlock, n.: Deceased rastaman. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
Date:Wed, 13 Sep 2000 09:25:28 -0400 (EDT) From: "Richard B. Johnson" <[EMAIL PROTECTED]> I haven't a clue why a UID/GID=0 process can't acquire a controlling TTY. It probably is some bogosity to do with process groups of the init kernel thread which execve's init. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Tue, 12 Sep 2000, Ion Badulescu wrote:
> On Tue, 12 Sep 2000, Ion Badulescu wrote:
>
> > Maybe I'll play with main.c and see what happens if I force /dev/console
> > to become the controlling tty for init. Hmm... That could be dangerous for
> > init. Maybe a better idea would be to hack init so that it gives any
> > program started from inittab /dev/console as the controlling tty.
> >
> > You're the sysvinit maintainer, right? :) What do you think of this idea?
>
> ... and init already does the above. :-) Except for one case: the
> emergency shell doesn't get a controlling tty. The first mini-patch below
> takes care of that problem.
>
> This still doesn't solve the original problem, i.e. init (or whatever you
> pass as init) still doesn't get a controlling tty from the kernel.
> However, since init appears to be safe from these issues, it it fairly
> trivial to fix this in the kernel; the second patch below takes care of
> it. The patch is against 2.2.17 but will apply against pretty much any 2.2
> and 2.4 kernel. It's is for i386 only, but the fixup for other
> architectures is extremely obvious.
>
Without patching the kernel, I think I can show that there is something
basically wrong. The patch may just hide the problem.
Something seems to be wrong, even with using the first virtual
terminal, which is a 'tty' and should (must) be able to become a
a controlling terminal.
Here is a trace:
getpid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
close(3)= 0
This is a stock kernel version 2.2.15. The stuff necessary to make
'strace' run ends up with the 'init' PID of 6. FYI, it is a real
bear to 'strace' init's startup.
I haven't a clue why a UID/GID=0 process can't acquire a controlling
TTY.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote: > Don't patch the kernel. If init gets the controlling tty, and you > press ^C -> SIGINT gets sent to init -> init interprets this as > ctrl-alt-del ! Yes, choosing SIGINT as the signal sent to init on > ctrl-alt-del was probably not very bright (and it was my idea.. sorry) > but there's nothing we can do about it now. Oh, but init loses its controlling tty very early in the game, so that's not a major issue. Sure, you can probably win the race, but if you have access to the console keyboard at the time init is starting, you might as well press ctrl-alt-del and be done with it. On the other hand, if you replace init with a shell you definitely want it to get SIGINT's. > I'm already working on 2.79 and this section has already gotten > a complete overhaul. Good to hear that. In the meantime, the patch will save me from cursing myself and having to freeze in the machine room searching for the right reset button, after having started a ping on a control-less serial console. :-) Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Ion Badulescu: > This still doesn't solve the original problem, i.e. init (or whatever you > pass as init) still doesn't get a controlling tty from the kernel. And for *good* reason. > However, since init appears to be safe from these issues, it it fairly > trivial to fix this in the kernel; the second patch below takes care of > it. The patch is against 2.2.17 but will apply against pretty much any 2.2 > and 2.4 kernel. It's is for i386 only, but the fixup for other > architectures is extremely obvious. Don't patch the kernel. If init gets the controlling tty, and you press ^C -> SIGINT gets sent to init -> init interprets this as ctrl-alt-del ! Yes, choosing SIGINT as the signal sent to init on ctrl-alt-del was probably not very bright (and it was my idea.. sorry) but there's nothing we can do about it now. I'm already working on 2.79 and this section has already gotten a complete overhaul. Mike. -- Deadlock, n.: Deceased rastaman. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Ion Badulescu: This still doesn't solve the original problem, i.e. init (or whatever you pass as init) still doesn't get a controlling tty from the kernel. And for *good* reason. However, since init appears to be safe from these issues, it it fairly trivial to fix this in the kernel; the second patch below takes care of it. The patch is against 2.2.17 but will apply against pretty much any 2.2 and 2.4 kernel. It's is for i386 only, but the fixup for other architectures is extremely obvious. Don't patch the kernel. If init gets the controlling tty, and you press ^C - SIGINT gets sent to init - init interprets this as ctrl-alt-del ! Yes, choosing SIGINT as the signal sent to init on ctrl-alt-del was probably not very bright (and it was my idea.. sorry) but there's nothing we can do about it now. I'm already working on 2.79 and this section has already gotten a complete overhaul. Mike. -- Deadlock, n.: Deceased rastaman. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote: Don't patch the kernel. If init gets the controlling tty, and you press ^C - SIGINT gets sent to init - init interprets this as ctrl-alt-del ! Yes, choosing SIGINT as the signal sent to init on ctrl-alt-del was probably not very bright (and it was my idea.. sorry) but there's nothing we can do about it now. Oh, but init loses its controlling tty very early in the game, so that's not a major issue. Sure, you can probably win the race, but if you have access to the console keyboard at the time init is starting, you might as well press ctrl-alt-del and be done with it. On the other hand, if you replace init with a shell you definitely want it to get SIGINT's. I'm already working on 2.79 and this section has already gotten a complete overhaul. Good to hear that. In the meantime, the patch will save me from cursing myself and having to freeze in the machine room searching for the right reset button, after having started a ping on a control-less serial console. :-) Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Richard B. Johnson: Without patching the kernel, I think I can show that there is something basically wrong. The patch may just hide the problem. No. Something seems to be wrong, even with using the first virtual terminal, which is a 'tty' and should (must) be able to become a a controlling terminal. Only if you're the process group leader.. read drivers/char/tty_io.c function tiocsctty() This is a stock kernel version 2.2.15. The stuff necessary to make 'strace' run ends up with the 'init' PID of 6. FYI, it is a real bear to 'strace' init's startup. And that is the cause of you not being process group leader. Stick a setsid() before the tty stuff. Mike. -- Deadlock, n.: Deceased rastaman. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote:
According to Richard B. Johnson:
Without patching the kernel, I think I can show that there is something
basically wrong. The patch may just hide the problem.
No.
Try it.
Something seems to be wrong, even with using the first virtual
terminal, which is a 'tty' and should (must) be able to become a
a controlling terminal.
Only if you're the process group leader.. read drivers/char/tty_io.c
function tiocsctty()
And that is the cause of you not being process group leader.
Stick a setsid() before the tty stuff.
Mike.
Well 'init' was supposed to be the process group leader by default.
however, here is a trace with setsid() just to "make sure".
brk(0) = 0x8049fdc
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)= 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)= 0
mmap(0, 644232, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4000c000
mprotect(0x40097000, 74888, PROT_NONE) = 0
mmap(0x40097000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8b000) =
0x40097000
mmap(0x4009d000, 50312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|0x20, 4294967295,
0) = 0x4009d000
close(3)= 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_WRITE) = 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_EXEC) = 0
SYS_136(0, 0x1, 0x4009c02c, 0xb77c, 0xb774) = 0
getpid()= 6
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
brk(0) = 0x8049fdc
brk(0x804a02c) = 0x804a02c
brk(0x804b000) = 0x804b000
I think I remember, that there was a discussion several years ago that
"The first N processes are supposed to be special" so there may
be something bogus keeping them from having a controlling terminal.
Like they may be "marked" as having a controlling terminal, but they
don't really have one. This would cause tiocsctty() to return -EPERM
(line 1553 in tty_io.c).
I will make another experiment and attempt to release any 'controlling
terminal' before I make the call again.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Wed, 13 Sep 2000, David S. Miller wrote:
Date: Wed, 13 Sep 2000 09:25:28 -0400 (EDT)
From: "Richard B. Johnson" [EMAIL PROTECTED]
I haven't a clue why a UID/GID=0 process can't acquire a
controlling TTY.
It probably is some bogosity to do with process groups
of the init kernel thread which execve's init.
Later,
David S. Miller
[EMAIL PROTECTED]
-
I'm checking on it now. Here's a strace with setsid() ahead, same
problem:
close(3)= 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_WRITE) = 0
mprotect(0x4000c000, 569344, PROT_READ|PROT_EXEC) = 0
SYS_136(0, 0x1, 0x4009c02c, 0xb77c, 0xb774) = 0
getpid()= 6
setsid()= 6
open("/dev/tty1", O_RDWR|O_NONBLOCK)= 3
fcntl(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
brk(0) = 0x8049fdc
brk(0x804a02c) = 0x804a02c
brk(0x804b000) = 0x804b000
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
In article <[EMAIL PROTECTED]> you wrote: > I like this idea a lot (the latter - making /dev/console controlling > tty). On an old SunOS 4 machine I once worked with, a Ctrl-C during the > execution of rc.sysinit would sent it terminate signals. So when the > NFS was hanging on mount because of a f***ed up network (or changed ip > address of server) you could hit ctrl-c during the rc script and the > mount would be sent the ctrl-c and would terminate, then the rest of the > rc script would continue (regular shell script behavior if I'm not > mistaken). If you look at the sysvinit code, you'll see that rc.sysinit does get a controlling tty, but the init code blocks all "user" signal (such as SIGINT) before executing it. I assume this is done to prevent some security problems, though I question its utility -- it's certainly useful to ctrl-c out of a screwed up rc.sysinit, and the script can block those signals itself if it wishes to. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Tue, 12 Sep 2000, Ion Badulescu wrote:
> Maybe I'll play with main.c and see what happens if I force /dev/console
> to become the controlling tty for init. Hmm... That could be dangerous for
> init. Maybe a better idea would be to hack init so that it gives any
> program started from inittab /dev/console as the controlling tty.
>
> You're the sysvinit maintainer, right? :) What do you think of this idea?
... and init already does the above. :-) Except for one case: the
emergency shell doesn't get a controlling tty. The first mini-patch below
takes care of that problem.
This still doesn't solve the original problem, i.e. init (or whatever you
pass as init) still doesn't get a controlling tty from the kernel.
However, since init appears to be safe from these issues, it it fairly
trivial to fix this in the kernel; the second patch below takes care of
it. The patch is against 2.2.17 but will apply against pretty much any 2.2
and 2.4 kernel. It's is for i386 only, but the fixup for other
architectures is extremely obvious.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
--- sysvinit-2.78/src/init.c.orig Tue Sep 12 04:31:47 2000
+++ sysvinit-2.78/src/init.cTue Sep 12 04:15:10 2000
@@ -88,7 +88,7 @@
CHILD *newFamily = NULL; /* The list after inittab re-read */
CHILD ch_emerg = { /* Emergency shell */
- 0, 0, 0, 0, 0,
+ WAITING, 0, 0, 0, 0,
"~~",
"S",
3,
--- tmp/linux-2.2.17/include/asm-i386/unistd.h Wed Jan 20 11:06:24 1999
+++ linux-2.2.17/include/asm-i386/unistd.h Tue Sep 12 17:56:07 2000
@@ -301,6 +301,7 @@
static inline _syscall1(int,_exit,int,exitcode)
static inline _syscall3(pid_t,waitpid,pid_t,pid,int *,wait_stat,int,options)
static inline _syscall1(int,delete_module,const char *,name)
+static inline _syscall3(int,ioctl,int,d,int,request,long,argp)
static inline pid_t wait(int * wait_stat)
{
--- tmp/linux-2.2.17/init/main.cWed Sep 6 12:40:14 2000
+++ linux-2.2.17/init/main.cTue Sep 12 18:44:02 2000
@@ -1607,6 +1604,7 @@
static int init(void * unused)
{
lock_kernel();
+ setsid();
do_basic_setup();
/*
@@ -1622,7 +1620,9 @@
(void) dup(0);
(void) dup(0);
-
+ if (ioctl(0, TIOCSCTTY, 1) < 0)
+ printk("Error while establishing a controlling tty.\n");
+
/*
* We try each of these until one succeeds.
*
Re: Booting into /bin/bash
Ion Badulescu wrote: > > > Maybe I'll play with main.c and see what happens if I force /dev/console > to become the controlling tty for init. Hmm... That could be dangerous for > init. Maybe a better idea would be to hack init so that it gives any > program started from inittab /dev/console as the controlling tty. > I like this idea a lot (the latter - making /dev/console controlling tty). On an old SunOS 4 machine I once worked with, a Ctrl-C during the execution of rc.sysinit would sent it terminate signals. So when the NFS was hanging on mount because of a f***ed up network (or changed ip address of server) you could hit ctrl-c during the rc script and the mount would be sent the ctrl-c and would terminate, then the rest of the rc script would continue (regular shell script behavior if I'm not mistaken). David Mansfield - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
> only a alias for a virtual console, therefore it can send signals. I guess > the break char is simply not set to ^C. use stty to set break to ^c and then > save the settings to ioctl.save. This will be restored by init. Or if you > want to avoid init, set stty by hand. When I ran into this problem last I tried to press Ctrl-A through Ctrl-\ to see what happens. All of them display except for Ctrl-C, Ctrl-Z and Ctrl-\, so they do have their meanings, just don't send signals. I thought this was because process 1 is special (isn't there a kill protection for init?); next I'll try the /dev/tty1 trick. Olaf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Tue, 12 Sep 2000, Miquel van Smoorenburg wrote: > It is a tty, it's just that if you open(2) it, it doesn't become > your _controlling_ tty by default. See drivers/char/tty_io.c (I > think, that's from the top of my head). Then I guess the kernel doesn't perform the proper setup when it opens /dev/console and then hands it over to init. Indeed, main.c simply opens /dev/console, dup()'s the descriptor twice (for stdout and stderr) and then exec's init. > You can always force it to become the controlling tty using TIOCSCTTY, > but that is kind of hard in a shell script. But the trick with > reopening stdin/stdout/stderr using /dev/tty1 should work. I don't want to rely on /dev/tty1. Many of my machines are on serial console, so that would be wrong anyway. The problem is that sometimes there is a problem in the start-up process, and I get a sulogin prompt which I can't even ctrl-d to continue! Maybe I'll play with main.c and see what happens if I force /dev/console to become the controlling tty for init. Hmm... That could be dangerous for init. Maybe a better idea would be to hack init so that it gives any program started from inittab /dev/console as the controlling tty. You're the sysvinit maintainer, right? :) What do you think of this idea? Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Ion Badulescu: > In article <8pjlk6$vnf$[EMAIL PROTECTED]> you wrote: > > >>However, ^C does not stop anything. No signal gets sent to anybody. > >>I don't want to make it too large because it won't fit on a floppy > >>if I do. > > > > That means you don't have a controlling tty. > > But why is /dev/console not a tty? Is there any good reason, > or is just "because nobody has done it"? It is a tty, it's just that if you open(2) it, it doesn't become your _controlling_ tty by default. See drivers/char/tty_io.c (I think, that's from the top of my head). You can always force it to become the controlling tty using TIOCSCTTY, but that is kind of hard in a shell script. But the trick with reopening stdin/stdout/stderr using /dev/tty1 should work. And indeed, as has been pointed out on this list, it could be that /dev/console is actually /dev/lp0 which isn't a tty at all. Could cause some weirdness - I never really tried it, or read that part of the source code though Mike. -- Deadlock, n.: Deceased rastaman. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Ion Badulescu: In article 8pjlk6$vnf$[EMAIL PROTECTED] you wrote: However, ^C does not stop anything. No signal gets sent to anybody. I don't want to make it too large because it won't fit on a floppy if I do. That means you don't have a controlling tty. But why is /dev/console not a tty? Is there any good reason, or is just "because nobody has done it"? It is a tty, it's just that if you open(2) it, it doesn't become your _controlling_ tty by default. See drivers/char/tty_io.c (I think, that's from the top of my head). You can always force it to become the controlling tty using TIOCSCTTY, but that is kind of hard in a shell script. But the trick with reopening stdin/stdout/stderr using /dev/tty1 should work. And indeed, as has been pointed out on this list, it could be that /dev/console is actually /dev/lp0 which isn't a tty at all. Could cause some weirdness - I never really tried it, or read that part of the source code though Mike. -- Deadlock, n.: Deceased rastaman. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Tue, 12 Sep 2000, Miquel van Smoorenburg wrote: It is a tty, it's just that if you open(2) it, it doesn't become your _controlling_ tty by default. See drivers/char/tty_io.c (I think, that's from the top of my head). Then I guess the kernel doesn't perform the proper setup when it opens /dev/console and then hands it over to init. Indeed, main.c simply opens /dev/console, dup()'s the descriptor twice (for stdout and stderr) and then exec's init. You can always force it to become the controlling tty using TIOCSCTTY, but that is kind of hard in a shell script. But the trick with reopening stdin/stdout/stderr using /dev/tty1 should work. I don't want to rely on /dev/tty1. Many of my machines are on serial console, so that would be wrong anyway. The problem is that sometimes there is a problem in the start-up process, and I get a sulogin prompt which I can't even ctrl-d to continue! Maybe I'll play with main.c and see what happens if I force /dev/console to become the controlling tty for init. Hmm... That could be dangerous for init. Maybe a better idea would be to hack init so that it gives any program started from inittab /dev/console as the controlling tty. You're the sysvinit maintainer, right? :) What do you think of this idea? Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
Ion Badulescu wrote: Maybe I'll play with main.c and see what happens if I force /dev/console to become the controlling tty for init. Hmm... That could be dangerous for init. Maybe a better idea would be to hack init so that it gives any program started from inittab /dev/console as the controlling tty. I like this idea a lot (the latter - making /dev/console controlling tty). On an old SunOS 4 machine I once worked with, a Ctrl-C during the execution of rc.sysinit would sent it terminate signals. So when the NFS was hanging on mount because of a f***ed up network (or changed ip address of server) you could hit ctrl-c during the rc script and the mount would be sent the ctrl-c and would terminate, then the rest of the rc script would continue (regular shell script behavior if I'm not mistaken). David Mansfield - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Mon, 11 Sep 2000, Ion Badulescu wrote: >In article <8pjlk6$vnf$[EMAIL PROTECTED]> you wrote: > >>>However, ^C does not stop anything. No signal gets sent to anybody. >>>I don't want to make it too large because it won't fit on a floppy >>>if I do. >> >> That means you don't have a controlling tty. > >But why is /dev/console not a tty? Is there any good reason, >or is just "because nobody has done it"? Sometimes /dev/console is a printer, or an uninitialized tty being used as a printer (serial dot matrix printers make excellent trace logs). -- - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
In article <[EMAIL PROTECTED]>, Richard B. Johnson <[EMAIL PROTECTED]> wrote: >Whmm. I have a shell-script that makes a RAM-Disk bootable "Rescue Disk". >It allows one to boot from two floppies and repair stuff, even execute >vi, fdisk, mke2fs, tar, tar-gz, etc. Just about everything one would >need (even modules) to rescue a system. > >However, ^C does not stop anything. No signal gets sent to anybody. >I don't want to make it too large because it won't fit on a floppy >if I do. That means you don't have a controlling tty. Try opening /dev/tty1 instead of /dev/console. Something like this should do it: #! /bin/bash # Get a real controlling tty instead of /dev/console exec 0<>/dev/tty1 1>&0 2>&0 Mike. -- Deadlock, n.: Deceased rastaman. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Mon, 11 Sep 2000, Adam wrote:
> > Does anybody know off the top of their head if there is an easy
> > way to have ^C work with /bin/bash as a shell, without having
> > to set up ptys?? Just setting terminal parameters to allow signals
> > doesn't do anything.
>
> not exactly the answer, but what I do is just run command 'open bash' few
> times and create in this way few ready-to-use shells.
>
Whmm. I have a shell-script that makes a RAM-Disk bootable "Rescue Disk".
It allows one to boot from two floppies and repair stuff, even execute
vi, fdisk, mke2fs, tar, tar-gz, etc. Just about everything one would
need (even modules) to rescue a system.
However, ^C does not stop anything. No signal gets sent to anybody.
I don't want to make it too large because it won't fit on a floppy
if I do.
I thought I did everything right, but
The shell-script is appended.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
#!/bin/sh
#
#
export VER=$1
RAMDISK_IMAGE=/tmp/RamImage-${VER}
RAMDISK=/tmp/Ramdisk
TMPF=/tmp/TmpExe
TMPC=/tmp/TmpC.c
DISKSIZE=4096
SYS=/usr/src/linux-${VER}/arch/i386/boot/bzImage
if [ "$1" = "" ] ;
then
echo "Usage:"
echo "Make_Rescue "
exit 1
fi
if [ ! -f ${SYS} ] ;
then
echo "File not found, ${SYS}"
exit 1
fi
if ! dd if=/dev/fd0 of=/dev/null bs=1k count=1 2>/dev/null ;
then
echo "Floppy drive error!"
echo "Maybe no diskette in the drive?"
exit 1
fi
#
# Make a RAM Disk file and mount it using the loop device.
# Remove the lost+found directory to save space.
#
umount ${RAMDISK} 2>/dev/null
rm -rf ${RAMDISK} 2>/dev/null
mkdir ${RAMDISK} 2>/dev/null
dd if=/dev/zero of=${RAMDISK_IMAGE} bs=1k count=${DISKSIZE}
/sbin/mke2fs -Fq ${RAMDISK_IMAGE} ${DISKSIZE}
mount -o loop -t ext2 ${RAMDISK_IMAGE} ${RAMDISK}
rmdir ${RAMDISK}/lost+found
#
# Make the required directories in the RAM Disk.
#
mkdir -m 777 ${RAMDISK}/dev
mkdir -m 777 ${RAMDISK}/etc
mkdir -m 777 ${RAMDISK}/lib
mkdir -m 777 ${RAMDISK}/usr
mkdir -m 777 ${RAMDISK}/usr/local
mkdir -m 777 ${RAMDISK}/usr/bin
mkdir -m 777 ${RAMDISK}/sbin
mkdir -m 777 ${RAMDISK}/tmp
mkdir -m 777 ${RAMDISK}/proc
mkdir -m 777 ${RAMDISK}/mnt
#
# Make the required devices.
#
mknod ${RAMDISK}/dev/null c 1 3
mknod ${RAMDISK}/dev/ram0 b 1 0
mknod ${RAMDISK}/dev/ram1 b 1 1
mknod ${RAMDISK}/dev/memc 1 1
mknod ${RAMDISK}/dev/ttyS0 c 4 64
mknod ${RAMDISK}/dev/tty0 c 4 0
mknod ${RAMDISK}/dev/tty1 c 4 1
mknod ${RAMDISK}/dev/tty2 c 4 2
mknod ${RAMDISK}/dev/tty3 c 4 3
mknod ${RAMDISK}/dev/tty4 c 4 4
mknod ${RAMDISK}/dev/ttyc 5 0
mknod ${RAMDISK}/dev/ttyp0 c 3 0
mknod ${RAMDISK}/dev/ttyp1 c 3 1
mknod ${RAMDISK}/dev/ttyp2 c 3 2
mknod ${RAMDISK}/dev/ttyp3 c 3 3
mknod ${RAMDISK}/dev/ttyp4 c 3 4
mknod ${RAMDISK}/dev/ttyp5 c 3 5
mknod ${RAMDISK}/dev/ptyp0 c 2 0
mknod ${RAMDISK}/dev/ptyp1 c 2 1
mknod ${RAMDISK}/dev/ptyp2 c 2 2
mknod ${RAMDISK}/dev/ptyp3 c 2 3
mknod ${RAMDISK}/dev/ptyp4 c 2 4
mknod ${RAMDISK}/dev/ptyp5 c 2 5
mknod ${RAMDISK}/dev/zero c 1 5
mknod ${RAMDISK}/dev/sdab 8 0
mknod ${RAMDISK}/dev/sda1 b 8 1
mknod ${RAMDISK}/dev/sda2 b 8 2
mknod ${RAMDISK}/dev/sdbb 8 16
mknod ${RAMDISK}/dev/sdb1 b 8 17
mknod ${RAMDISK}/dev/sdb2 b 8 18
mknod ${RAMDISK}/dev/sdcb 8 32
mknod ${RAMDISK}/dev/sdc1 b 8 33
mknod ${RAMDISK}/dev/sdc2 b 8 34
mknod ${RAMDISK}/dev/st0c 9 0
mknod ${RAMDISK}/dev/st1c 9 1
mknod ${RAMDISK}/dev/st2c 9 2
mknod ${RAMDISK}/dev/st3c 9 4
mknod ${RAMDISK}/dev/st4c 9 5
mknod ${RAMDISK}/dev/fd0b 2 0
mknod ${RAMDISK}/dev/hdab 3 0
mknod ${RAMDISK}/dev/hda1 b 3 1
mknod ${RAMDISK}/dev/hda2 b 3 2
#
# Set some compatibility links.
#
ln -s /dev/tty0 ${RAMDISK}/dev/systty
ln -s /dev/tty0 ${RAMDISK}/dev/console
ln -s /dev/ram1 ${RAMDISK}/dev/ram
ln -s /lib ${RAMDISK}/usr/lib
ln -s /sbin ${RAMDISK}/bin
ln -s /lib ${RAMDISK}/usr/local/lib
ln -s /lib/ld-linux.so.2${RAMDISK}/lib/ld.so
ln -s /sbin/bash${RAMDISK}/sbin/sh
ln -s /sbin/gunzip ${RAMDISK}/sbin/gzip
#
#
# Copy some files and libraries.
#
files="modprobe bash rm mkdir rmdir cat ls cp mount umount \
insmod gunzip tar df"
for x in $files ; do cp `which $x` ${TMPF} ; strip ${TMPF} ;\
cp ${TMPF} ${RAMDISK}/sbin/$x ; done
cp /lib/libc.so.6 ${TMPF}
strip ${TMPF}
cp ${TMPF} ${RAMDISK}/lib/libc.so.6
cp /lib/libm.so.6 ${TMPF}
strip
Re: Booting into /bin/bash
> Does anybody know off the top of their head if there is an easy > way to have ^C work with /bin/bash as a shell, without having > to set up ptys?? Just setting terminal parameters to allow signals > doesn't do anything. not exactly the answer, but what I do is just run command 'open bash' few times and create in this way few ready-to-use shells. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
On Mon, 11 Sep 2000, Adam wrote:
Does anybody know off the top of their head if there is an easy
way to have ^C work with /bin/bash as a shell, without having
to set up ptys?? Just setting terminal parameters to allow signals
doesn't do anything.
not exactly the answer, but what I do is just run command 'open bash' few
times and create in this way few ready-to-use shells.
Whmm. I have a shell-script that makes a RAM-Disk bootable "Rescue Disk".
It allows one to boot from two floppies and repair stuff, even execute
vi, fdisk, mke2fs, tar, tar-gz, etc. Just about everything one would
need (even modules) to rescue a system.
However, ^C does not stop anything. No signal gets sent to anybody.
I don't want to make it too large because it won't fit on a floppy
if I do.
I thought I did everything right, but
The shell-script is appended.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
#!/bin/sh
#
#
export VER=$1
RAMDISK_IMAGE=/tmp/RamImage-${VER}
RAMDISK=/tmp/Ramdisk
TMPF=/tmp/TmpExe
TMPC=/tmp/TmpC.c
DISKSIZE=4096
SYS=/usr/src/linux-${VER}/arch/i386/boot/bzImage
if [ "$1" = "" ] ;
then
echo "Usage:"
echo "Make_Rescue version"
exit 1
fi
if [ ! -f ${SYS} ] ;
then
echo "File not found, ${SYS}"
exit 1
fi
if ! dd if=/dev/fd0 of=/dev/null bs=1k count=1 2/dev/null ;
then
echo "Floppy drive error!"
echo "Maybe no diskette in the drive?"
exit 1
fi
#
# Make a RAM Disk file and mount it using the loop device.
# Remove the lost+found directory to save space.
#
umount ${RAMDISK} 2/dev/null
rm -rf ${RAMDISK} 2/dev/null
mkdir ${RAMDISK} 2/dev/null
dd if=/dev/zero of=${RAMDISK_IMAGE} bs=1k count=${DISKSIZE}
/sbin/mke2fs -Fq ${RAMDISK_IMAGE} ${DISKSIZE}
mount -o loop -t ext2 ${RAMDISK_IMAGE} ${RAMDISK}
rmdir ${RAMDISK}/lost+found
#
# Make the required directories in the RAM Disk.
#
mkdir -m 777 ${RAMDISK}/dev
mkdir -m 777 ${RAMDISK}/etc
mkdir -m 777 ${RAMDISK}/lib
mkdir -m 777 ${RAMDISK}/usr
mkdir -m 777 ${RAMDISK}/usr/local
mkdir -m 777 ${RAMDISK}/usr/bin
mkdir -m 777 ${RAMDISK}/sbin
mkdir -m 777 ${RAMDISK}/tmp
mkdir -m 777 ${RAMDISK}/proc
mkdir -m 777 ${RAMDISK}/mnt
#
# Make the required devices.
#
mknod ${RAMDISK}/dev/null c 1 3
mknod ${RAMDISK}/dev/ram0 b 1 0
mknod ${RAMDISK}/dev/ram1 b 1 1
mknod ${RAMDISK}/dev/memc 1 1
mknod ${RAMDISK}/dev/ttyS0 c 4 64
mknod ${RAMDISK}/dev/tty0 c 4 0
mknod ${RAMDISK}/dev/tty1 c 4 1
mknod ${RAMDISK}/dev/tty2 c 4 2
mknod ${RAMDISK}/dev/tty3 c 4 3
mknod ${RAMDISK}/dev/tty4 c 4 4
mknod ${RAMDISK}/dev/ttyc 5 0
mknod ${RAMDISK}/dev/ttyp0 c 3 0
mknod ${RAMDISK}/dev/ttyp1 c 3 1
mknod ${RAMDISK}/dev/ttyp2 c 3 2
mknod ${RAMDISK}/dev/ttyp3 c 3 3
mknod ${RAMDISK}/dev/ttyp4 c 3 4
mknod ${RAMDISK}/dev/ttyp5 c 3 5
mknod ${RAMDISK}/dev/ptyp0 c 2 0
mknod ${RAMDISK}/dev/ptyp1 c 2 1
mknod ${RAMDISK}/dev/ptyp2 c 2 2
mknod ${RAMDISK}/dev/ptyp3 c 2 3
mknod ${RAMDISK}/dev/ptyp4 c 2 4
mknod ${RAMDISK}/dev/ptyp5 c 2 5
mknod ${RAMDISK}/dev/zero c 1 5
mknod ${RAMDISK}/dev/sdab 8 0
mknod ${RAMDISK}/dev/sda1 b 8 1
mknod ${RAMDISK}/dev/sda2 b 8 2
mknod ${RAMDISK}/dev/sdbb 8 16
mknod ${RAMDISK}/dev/sdb1 b 8 17
mknod ${RAMDISK}/dev/sdb2 b 8 18
mknod ${RAMDISK}/dev/sdcb 8 32
mknod ${RAMDISK}/dev/sdc1 b 8 33
mknod ${RAMDISK}/dev/sdc2 b 8 34
mknod ${RAMDISK}/dev/st0c 9 0
mknod ${RAMDISK}/dev/st1c 9 1
mknod ${RAMDISK}/dev/st2c 9 2
mknod ${RAMDISK}/dev/st3c 9 4
mknod ${RAMDISK}/dev/st4c 9 5
mknod ${RAMDISK}/dev/fd0b 2 0
mknod ${RAMDISK}/dev/hdab 3 0
mknod ${RAMDISK}/dev/hda1 b 3 1
mknod ${RAMDISK}/dev/hda2 b 3 2
#
# Set some compatibility links.
#
ln -s /dev/tty0 ${RAMDISK}/dev/systty
ln -s /dev/tty0 ${RAMDISK}/dev/console
ln -s /dev/ram1 ${RAMDISK}/dev/ram
ln -s /lib ${RAMDISK}/usr/lib
ln -s /sbin ${RAMDISK}/bin
ln -s /lib ${RAMDISK}/usr/local/lib
ln -s /lib/ld-linux.so.2${RAMDISK}/lib/ld.so
ln -s /sbin/bash${RAMDISK}/sbin/sh
ln -s /sbin/gunzip ${RAMDISK}/sbin/gzip
#
#
# Copy some files and libraries.
#
files="modprobe bash rm mkdir rmdir cat ls cp mount umount \
insmod gunzip tar df"
for x in $files ; do cp `which $x` ${TMPF} ; strip ${TMPF} ;\
cp ${TMPF} ${RAMDISK}/sbin/$x ; done
cp /lib/libc.so.6 ${TMPF}
strip ${TMPF}
cp ${TMPF} ${RAMDISK}/lib/libc.so.6
cp /lib/libm.so.6 ${TMPF}
strip ${TMPF}
