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
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.
> >
> >
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
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
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
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
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
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
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,
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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.
>
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
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
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
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
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
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
> 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
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
36 matches
Mail list logo
