emergency or init=/bin/sh mode and terminal signals

emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

Hi,

There's a long-standing issue in init=/bin/sh mode: pressing control-C
doesn't send a SIGINT to programs running on the console. The incurred
typical pitfall is if one runs ping without a -c option... no way to
stop it!

This is because no session is set up by the kernel, and shells don't
start sessions on their own, so that no session (hence no controlling
tty) is set up.

The attached patch sets such session and controlling tty up, which fixes
the issue. The unfortunate effect is that init might be killed if one
presses control-C very fast after its start.

Samuel

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 460 bytes --]

--- linux-2.6.17-orig/init/main.c	2006-06-18 19:22:40.000000000 +0200
+++ linux-2.6.17-perso/init/main.c	2006-06-18 23:00:00.000000000 +0200
@@ -703,9 +703,13 @@
 	system_state = SYSTEM_RUNNING;
 	numa_default_policy();
 
+	sys_setsid();
+
 	if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
 		printk(KERN_WARNING "Warning: unable to open an initial console.\n");
 
+	sys_ioctl(0, TIOCSCTTY, 1);
+
 	(void) sys_dup(0);
 	(void) sys_dup(0);
 

Re: emergency or init=/bin/sh mode and terminal signals

[Willy Tarreau]

On Sun, Jun 18, 2006 at 11:23:03PM +0200, Samuel Thibault wrote:
> Hi,
> 
> There's a long-standing issue in init=/bin/sh mode: pressing control-C
> doesn't send a SIGINT to programs running on the console. The incurred
> typical pitfall is if one runs ping without a -c option... no way to
> stop it!
> 
> This is because no session is set up by the kernel, and shells don't
> start sessions on their own, so that no session (hence no controlling
> tty) is set up.
> 
> The attached patch sets such session and controlling tty up, which fixes
> the issue. The unfortunate effect is that init might be killed if one
> presses control-C very fast after its start.

This downside is a little problematic. Wouldn't it be possible to disable
the interrupt signal on the terminal, and let the user re-enable it when
needed using "stty intr ^C" ?

I too am used to starting with init=/bin/sh, but I'm also used to launch
ping in the background. However, if getting Ctrl-C working implies a risk
of killing init, then I'd rather keep it the old way.

> Samuel

Regards,
Willy

> --- linux-2.6.17-orig/init/main.c	2006-06-18 19:22:40.000000000 +0200
> +++ linux-2.6.17-perso/init/main.c	2006-06-18 23:00:00.000000000 +0200
> @@ -703,9 +703,13 @@
>  	system_state = SYSTEM_RUNNING;
>  	numa_default_policy();
>  
> +	sys_setsid();
> +
>  	if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
>  		printk(KERN_WARNING "Warning: unable to open an initial console.\n");
>  
> +	sys_ioctl(0, TIOCSCTTY, 1);
> +
>  	(void) sys_dup(0);
>  	(void) sys_dup(0);
>  

Re: emergency or init=/bin/sh mode and terminal signals

[Wakko Warner]

Samuel Thibault wrote:
> Hi,
> 
> There's a long-standing issue in init=/bin/sh mode: pressing control-C
> doesn't send a SIGINT to programs running on the console. The incurred
> typical pitfall is if one runs ping without a -c option... no way to
> stop it!
> 
> This is because no session is set up by the kernel, and shells don't
> start sessions on their own, so that no session (hence no controlling
> tty) is set up.
> 
> The attached patch sets such session and controlling tty up, which fixes
> the issue. The unfortunate effect is that init might be killed if one
> presses control-C very fast after its start.

Interesting idea, especially for a boot cd I built.

However, why not only set this if the shell is /bin/sh ?

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

Wakko Warner, le Sun 18 Jun 2006 18:39:06 -0400, a écrit :
> why not only set this if the shell is /bin/sh ?

Because you can't know that. /bin/sh is one example of shell, /bin/ash
is another /usr/bin/myprog is yet another...

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[Willy Tarreau]

On Mon, Jun 19, 2006 at 12:40:51AM +0200, Samuel Thibault wrote:
> Wakko Warner, le Sun 18 Jun 2006 18:39:06 -0400, a écrit :
> > why not only set this if the shell is /bin/sh ?
> 
> Because you can't know that. /bin/sh is one example of shell, /bin/ash
> is another /usr/bin/myprog is yet another...

another possibility would be to do it only if 'init=' has been specified,
since most of the time the kernel finds it itself.

> Samuel

Regards,
willy

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

Willy Tarreau, le Mon 19 Jun 2006 00:44:24 +0200, a écrit :
> On Mon, Jun 19, 2006 at 12:40:51AM +0200, Samuel Thibault wrote:
> > Wakko Warner, le Sun 18 Jun 2006 18:39:06 -0400, a écrit :
> > > why not only set this if the shell is /bin/sh ?
> > 
> > Because you can't know that. /bin/sh is one example of shell, /bin/ash
> > is another /usr/bin/myprog is yet another...
> 
> another possibility would be to do it only if 'init=' has been specified,
> since most of the time the kernel finds it itself.

Init needs to be patched for the emergency case then.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[Wakko Warner]

Samuel Thibault wrote:
> Wakko Warner, le Sun 18 Jun 2006 18:39:06 -0400, a ?crit :
> > why not only set this if the shell is /bin/sh ?
> 
> Because you can't know that. /bin/sh is one example of shell, /bin/ash
> is another /usr/bin/myprog is yet another...

I realized that before I sent the email.  /bin/sh is guaranteed (usually) to
be there.  I myself prefer zsh, but when I'm booting with init=, it's always
/bin/sh (unless I'm testing something else).  Of course, that's just me. 
The one time I did use init=/bin/zsh, it failed to function properly (forgot
the details), but booting with /bin/sh and exec zsh worked fine.

Is there any (non-embedded) linux systems out there that do not have
/bin/sh ?  On the boot cd I built, there is no /bin/sh but there is a
/bin/init (shell script with #! busybox ash  at the top)

Anyway, it's a thought.  Or you could only enable it if the init= is not
init (Any other inits?)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: emergency or init=/bin/sh mode and terminal signals

[Joshua Hudson]

I've got one lying around where /bin->/usr/bin and /usr is a mountpoint.
init=/sbin/sh boots at need.

Re: emergency or init=/bin/sh mode and terminal signals

[Albert Cahalan]

Samuel Thibault writes:

> The attached patch sets such session and controlling tty up, which fixes
> the issue. The unfortunate effect is that init might be killed if one
> presses control-C very fast after its start.

Doesn't the kernel protect process 1 from any signal
that it does not have a handler for?

I think there is no problem.

Re: emergency or init=/bin/sh mode and terminal signals

[Willy Tarreau]

On Mon, Jun 19, 2006 at 12:48:28AM +0200, Samuel Thibault wrote:
> Willy Tarreau, le Mon 19 Jun 2006 00:44:24 +0200, a écrit :
> > On Mon, Jun 19, 2006 at 12:40:51AM +0200, Samuel Thibault wrote:
> > > Wakko Warner, le Sun 18 Jun 2006 18:39:06 -0400, a écrit :
> > > > why not only set this if the shell is /bin/sh ?
> > > 
> > > Because you can't know that. /bin/sh is one example of shell, /bin/ash
> > > is another /usr/bin/myprog is yet another...
> > 
> > another possibility would be to do it only if 'init=' has been specified,
> > since most of the time the kernel finds it itself.
> 
> Init needs to be patched for the emergency case then.
 
why ? the goal is to reduce the risk of killing init. This risk remains only
if "init=..." was specified. In your case, it is permanent.

> Samuel

Regards,
willy

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

Willy Tarreau, le Mon 19 Jun 2006 05:59:10 +0200, a écrit :
> On Mon, Jun 19, 2006 at 12:48:28AM +0200, Samuel Thibault wrote:
> > Willy Tarreau, le Mon 19 Jun 2006 00:44:24 +0200, a écrit :
> > > On Mon, Jun 19, 2006 at 12:40:51AM +0200, Samuel Thibault wrote:
> > > > Wakko Warner, le Sun 18 Jun 2006 18:39:06 -0400, a écrit :
> > > > > why not only set this if the shell is /bin/sh ?
> > > > 
> > > > Because you can't know that. /bin/sh is one example of shell, /bin/ash
> > > > is another /usr/bin/myprog is yet another...
> > > 
> > > another possibility would be to do it only if 'init=' has been specified,
> > > since most of the time the kernel finds it itself.
> > 
> > Init needs to be patched for the emergency case then.
>  
> why ?

For the "emergency" case: for now, init doesn't create a session either
in such case.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

Albert Cahalan, le Sun 18 Jun 2006 23:47:51 -0400, a écrit :
> Samuel Thibault writes:
> 
> >The attached patch sets such session and controlling tty up, which fixes
> >the issue. The unfortunate effect is that init might be killed if one
> >presses control-C very fast after its start.
> 
> Doesn't the kernel protect process 1 from any signal
> that it does not have a handler for?

Ah, yes, indeed, forgot that.

> I think there is no problem.

Agreed.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[linux-os (Dick Johnson)]

On Sun, 18 Jun 2006, Samuel Thibault wrote:

> Hi,
>
> There's a long-standing issue in init=/bin/sh mode: pressing control-C
> doesn't send a SIGINT to programs running on the console. The incurred
> typical pitfall is if one runs ping without a -c option... no way to
> stop it!
>
> This is because no session is set up by the kernel, and shells don't
> start sessions on their own, so that no session (hence no controlling
> tty) is set up.
>
> The attached patch sets such session and controlling tty up, which fixes
> the issue. The unfortunate effect is that init might be killed if one
> presses control-C very fast after its start.
>
> Samuel
>

I don't think this is the correct behavior. You can't allow some
terminal input to affect init. It has been the de facto standard
in Unix, that the only time one should have a controlling terminal
is after somebody logs in and owns something to control. If you want
a controlling terminal from your emergency shell, please exec /bin/login.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.88 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
> I don't think this is the correct behavior. You can't allow some
> terminal input to affect init. It has been the de facto standard
> in Unix, that the only time one should have a controlling terminal
> is after somebody logs in and owns something to control. If you want
> a controlling terminal from your emergency shell, please exec /bin/login.

Ok, but people don't know that: they're given a shell, and wonder why on
hell ^C doesn't work...

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[linux-os (Dick Johnson)]

On Mon, 19 Jun 2006, Samuel Thibault wrote:

> linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
>> I don't think this is the correct behavior. You can't allow some
>> terminal input to affect init. It has been the de facto standard
>> in Unix, that the only time one should have a controlling terminal
>> is after somebody logs in and owns something to control. If you want
>> a controlling terminal from your emergency shell, please exec /bin/login.
>
> Ok, but people don't know that: they're given a shell, and wonder why on
> hell ^C doesn't work...
>
> Samuel

Maybe, but you shouldn't modify the kernel for "training". The kernel
needs to be sacrosanct.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.88 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: emergency or init=/bin/sh mode and terminal signals

[Jan Engelhardt]

>Hi,
>
>There's a long-standing issue in init=/bin/sh mode: pressing control-C
>doesn't send a SIGINT to programs running on the console. The incurred
>typical pitfall is if one runs ping without a -c option... no way to
>stop it!

Worse, I can observe same behavior when using "-b", i.e. init=/sbin/init 
called with -b (read: `/sbin/init -b`), and init starts a su shell before 
continuing. No ^C either to my knowledge.
rpm -q sysvinit: 2.86


Jan Engelhardt
-- 

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

Jan Engelhardt, le Mon 19 Jun 2006 14:08:28 +0200, a écrit :
> >Hi,
> >
> >There's a long-standing issue in init=/bin/sh mode: pressing control-C
> >doesn't send a SIGINT to programs running on the console. The incurred
> >typical pitfall is if one runs ping without a -c option... no way to
> >stop it!
> 
> Worse, I can observe same behavior when using "-b", i.e. init=/sbin/init 
> called with -b (read: `/sbin/init -b`),

That's equivalent to the "emergency" mode.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

Hi,

Willy Tarreau, le Sun 18 Jun 2006 23:33:42 +0200, a écrit :
> I too am used to starting with init=/bin/sh, but I'm also used to launch
> ping in the background. However, if getting Ctrl-C working implies a risk
> of killing init, then I'd rather keep it the old way.

Maybe you should rather use init=/bin/login . If your login program is
smart enough, it will set a session and thus ^C will work.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

Hi,

linux-os (Dick Johnson), le Mon 19 Jun 2006 08:05:01 -0400, a écrit :
> On Mon, 19 Jun 2006, Samuel Thibault wrote:
> > linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
> >> I don't think this is the correct behavior. You can't allow some
> >> terminal input to affect init. It has been the de facto standard
> >> in Unix, that the only time one should have a controlling terminal
> >> is after somebody logs in and owns something to control. If you want
> >> a controlling terminal from your emergency shell, please exec /bin/login.
> >
> > Ok, but people don't know that: they're given a shell, and wonder why on
> > hell ^C doesn't work...
> 
> Maybe, but you shouldn't modify the kernel for "training". The kernel
> needs to be sacrosanct.

?? I can't find out what I should understand.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
> You can't allow some terminal input to affect init. It has been the
> de facto standard in Unix, that the only time one should have a
> controlling terminal is after somebody logs in and owns something to
> control.

Ok. The following still makes sense, doesn't it? (i.e. set a session for
the emergency shell)

--- linux-2.6.17-orig/init/main.c	2006-06-18 19:22:40.000000000 +0200
+++ linux-2.6.17-perso/init/main.c	2006-06-20 00:07:07.000000000 +0200
@@ -729,6 +729,11 @@
 	run_init_process("/sbin/init");
 	run_init_process("/etc/init");
 	run_init_process("/bin/init");
+
+	/* Set a session for the shell.  */
+	sys_setsid();
+	sys_ioctl(0, TIOCSCTTY, 1);
+
 	run_init_process("/bin/sh");
 
 	panic("No init found.  Try passing init= option to kernel.");

Re: emergency or init=/bin/sh mode and terminal signals

[David Luyer]

On 20/6/06 8:09 AM, "Samuel Thibault" <samuel.thibault@ens-lyon.org> wrote:
> linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
>> You can't allow some terminal input to affect init. It has been the
>> de facto standard in Unix, that the only time one should have a
>> controlling terminal is after somebody logs in and owns something to
>> control.
> 
> Ok. The following still makes sense, doesn't it? (i.e. set a session for
> the emergency shell)
> 
> --- linux-2.6.17-orig/init/main.c 2006-06-18 19:22:40.000000000 +0200
> +++ linux-2.6.17-perso/init/main.c 2006-06-20 00:07:07.000000000 +0200
> @@ -729,6 +729,11 @@
> run_init_process("/sbin/init");
> run_init_process("/etc/init");
> run_init_process("/bin/init");
> +
> + /* Set a session for the shell.  */
> + sys_setsid();
> + sys_ioctl(0, TIOCSCTTY, 1);
> +
> run_init_process("/bin/sh");
>  
> panic("No init found.  Try passing init= option to kernel.");

What if people are booting via /bin/sh and then setting up
their custom chroot's and init(s), and don't want these init(s) to
be part of a session?

It is also particularly possible for an embedded system to start
up via /bin/sh running /etc/profile rather than using an init type
program.

Also, the above doesn't help people specifying "init=/bin/sh" on the
command line (as per the original post subject).  The real solution
is for them to specify a different init= or run/exec something to set
up their tty and session once logged in.

David.

Re: emergency or init=/bin/sh mode and terminal signals

[Willy Tarreau]

On Tue, Jun 20, 2006 at 10:02:23AM +1000, David Luyer wrote:
> On 20/6/06 8:09 AM, "Samuel Thibault" <samuel.thibault@ens-lyon.org> wrote:
> > linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
> >> You can't allow some terminal input to affect init. It has been the
> >> de facto standard in Unix, that the only time one should have a
> >> controlling terminal is after somebody logs in and owns something to
> >> control.
> > 
> > Ok. The following still makes sense, doesn't it? (i.e. set a session for
> > the emergency shell)
> > 
> > --- linux-2.6.17-orig/init/main.c 2006-06-18 19:22:40.000000000 +0200
> > +++ linux-2.6.17-perso/init/main.c 2006-06-20 00:07:07.000000000 +0200
> > @@ -729,6 +729,11 @@
> > run_init_process("/sbin/init");
> > run_init_process("/etc/init");
> > run_init_process("/bin/init");
> > +
> > + /* Set a session for the shell.  */
> > + sys_setsid();
> > + sys_ioctl(0, TIOCSCTTY, 1);
> > +
> > run_init_process("/bin/sh");
> >  
> > panic("No init found.  Try passing init= option to kernel.");
> 
> What if people are booting via /bin/sh and then setting up
> their custom chroot's and init(s), and don't want these init(s) to
> be part of a session?
> 
> It is also particularly possible for an embedded system to start
> up via /bin/sh running /etc/profile rather than using an init type
> program.
> 
> Also, the above doesn't help people specifying "init=/bin/sh" on the
> command line (as per the original post subject).  The real solution
> is for them to specify a different init= or run/exec something to set
> up their tty and session once logged in.

Then, I think that a solution which would fit everyone's needs would be
to add a command line parameter (eg: "setsid=1") which will allow
the two lines to be executed whatever the init or shell. This way,
you want a session ? -> "init=/bin/sh setsid=1".

Not particularly difficult to use and does not risk to break existing
setups.

> David.

Cheers,
Willy

Re: emergency or init=/bin/sh mode and terminal signals

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Tue, 20 Jun 2006 06:28:02 +0200, Willy Tarreau said:
> Then, I think that a solution which would fit everyone's needs would be
> to add a command line parameter (eg: "setsid=1") which will allow
> the two lines to be executed whatever the init or shell. This way,
> you want a session ? -> "init=/bin/sh setsid=1".

Get 2 for the price of one:

init=/bin/something_that_does_setsid_in_userspace_and_doesnt_clutter_kernel

Or once you get a # prompt from /bin/sh, 'exec /bin/something_saner'.

Remember - if it's trivially done in userspace, it probably shouldn't
be cluttering the kernel.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

David Luyer, le Tue 20 Jun 2006 10:02:23 +1000, a écrit :
> On 20/6/06 8:09 AM, "Samuel Thibault" <samuel.thibault@ens-lyon.org> wrote:
> > linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
> >> You can't allow some terminal input to affect init. It has been the
> >> de facto standard in Unix, that the only time one should have a
> >> controlling terminal is after somebody logs in and owns something to
> >> control.
> > 
> > Ok. The following still makes sense, doesn't it? (i.e. set a session for
> > the emergency shell)
> > 
> > --- linux-2.6.17-orig/init/main.c 2006-06-18 19:22:40.000000000 +0200
> > +++ linux-2.6.17-perso/init/main.c 2006-06-20 00:07:07.000000000 +0200
> > @@ -729,6 +729,11 @@
> > run_init_process("/sbin/init");
> > run_init_process("/etc/init");
> > run_init_process("/bin/init");
> > +
> > + /* Set a session for the shell.  */
> > + sys_setsid();
> > + sys_ioctl(0, TIOCSCTTY, 1);
> > +
> > run_init_process("/bin/sh");
> >  
> > panic("No init found.  Try passing init= option to kernel.");
> 
> What if people are booting via /bin/sh and then setting up
> their custom chroot's and init(s), and don't want these init(s) to
> be part of a session?

The problem is that you can't distinguish that from usual init booting:

	if (execute_command) {
		run_init_process(execute_command);
		printk(KERN_WARNING "Failed to execute %s.  Attempting "
					"defaults...\n", execute_command);
	}
	run_init_process("/sbin/init");

If you setsid() in the if(execute_command) statement, and the
execute_command fails, you get to run init in a session.

> It is also particularly possible for an embedded system to start
> up via /bin/sh running /etc/profile rather than using an init type
> program.

Then people writing that embedded system should use /bin/login instead.

> Also, the above doesn't help people specifying "init=/bin/sh" on the
> command line (as per the original post subject).  The real solution
> is for them to specify a different init= or run/exec something to set
> up their tty and session once logged in.

Yes. And the problem is that people usually don't know about sessions
etc, and will just grumble "linux can't work".

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[linux-os (Dick Johnson)]

On Mon, 19 Jun 2006, Samuel Thibault wrote:

> Hi,
>
> Willy Tarreau, le Sun 18 Jun 2006 23:33:42 +0200, a écrit :
>> I too am used to starting with init=/bin/sh, but I'm also used to launch
>> ping in the background. However, if getting Ctrl-C working implies a risk
>> of killing init, then I'd rather keep it the old way.
>
> Maybe you should rather use init=/bin/login . If your login program is
> smart enough, it will set a session and thus ^C will work.
>
> Samuel
> -

Actually, a rather trivial program can be written, the name of
which you define as init on the command-line 'init=/bin/myprog'.
This program sets up the controlling terminal, then exec()s
/bin/bash or whatever shell you want. Since it's exec()ed, the
PID remains at 1 so after you have fixed whatever you needed
to fix, you can execute `exec /sbin/init auto` and continue
with a normal startup. This is certainly cleaner than poking
holes in the kernel.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.72 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: emergency or init=/bin/sh mode and terminal signals

[linux-os (Dick Johnson)]

On Mon, 19 Jun 2006, Samuel Thibault wrote:

> linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
>> You can't allow some terminal input to affect init. It has been the
>> de facto standard in Unix, that the only time one should have a
>> controlling terminal is after somebody logs in and owns something to
>> control.
>
> Ok. The following still makes sense, doesn't it? (i.e. set a session for
> the emergency shell)
>
> --- linux-2.6.17-orig/init/main.c	2006-06-18 19:22:40.000000000 +0200
> +++ linux-2.6.17-perso/init/main.c	2006-06-20 00:07:07.000000000 +0200
> @@ -729,6 +729,11 @@
> 	run_init_process("/sbin/init");
> 	run_init_process("/etc/init");
> 	run_init_process("/bin/init");
> +
> +	/* Set a session for the shell.  */
> +	sys_setsid();
> +	sys_ioctl(0, TIOCSCTTY, 1);
> +
> 	run_init_process("/bin/sh");
>
> 	panic("No init found.  Try passing init= option to kernel.");
>

Well this makes 'sense' however, you should not modify the kernel
for this, you should do (trivialized and not tested):

int main(int count, char *argv[], char *env[])
{
    setsid();
    strcpy(argv[0], "/bin/bash");
    ioctl(0, TIOCSCTTY, 1);
    execve(argv[0], argv, env);
}

That gets you a shell with ^C capability. You could also
set up some signal handlers to minimize the potential of
killing your 'init' even though bash will set up its own.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.72 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

linux-os (Dick Johnson), le Tue 20 Jun 2006 07:26:39 -0400, a écrit :
> 
> On Mon, 19 Jun 2006, Samuel Thibault wrote:
> 
> > linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
> >> You can't allow some terminal input to affect init. It has been the
> >> de facto standard in Unix, that the only time one should have a
> >> controlling terminal is after somebody logs in and owns something to
> >> control.
> >
> > Ok. The following still makes sense, doesn't it? (i.e. set a session for
> > the emergency shell)
> >
> > --- linux-2.6.17-orig/init/main.c	2006-06-18 19:22:40.000000000 +0200
> > +++ linux-2.6.17-perso/init/main.c	2006-06-20 00:07:07.000000000 +0200
> > @@ -729,6 +729,11 @@
> > 	run_init_process("/sbin/init");
> > 	run_init_process("/etc/init");
> > 	run_init_process("/bin/init");
> > +
> > +	/* Set a session for the shell.  */
> > +	sys_setsid();
> > +	sys_ioctl(0, TIOCSCTTY, 1);
> > +
> > 	run_init_process("/bin/sh");
> >
> > 	panic("No init found.  Try passing init= option to kernel.");
> >
> 
> Well this makes 'sense' however, you should not modify the kernel
> for this,

Why not? /bin/sh is not supposed to start a session, so in this case it
should be up to the kernel to start it.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[linux-os (Dick Johnson)]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]


On Mon, 19 Jun 2006, Samuel Thibault wrote:

> linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
>> I don't think this is the correct behavior. You can't allow some
>> terminal input to affect init. It has been the de facto standard
>> in Unix, that the only time one should have a controlling terminal
>> is after somebody logs in and owns something to control. If you want
>> a controlling terminal from your emergency shell, please exec /bin/login.
>
> Ok, but people don't know that: they're given a shell, and wonder why on
> hell ^C doesn't work...
>
> Samuel

Attached is a simple program called shell. You can copy it to /bin/shell
and use it instead of /bin/bash for your emergency shell. It provides
for terminal control, plus it protects against exit because it does
its work from a fork()ed process and if that exits another is fork()ed
forever.

It has been tested and works, however after you do your emergency
stuff, you can't (correctly) exec /sbin/init as you could with
bash alone, because the executing task does not have PID=1. Instead,
you will have to manually unmount any file-systems you mounted, then
reboot using Ctr-Alt-Del.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.88 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

[-- Attachment #2: shell.tar.gz --]
[-- Type: APPLICATION/x-gzip, Size: 5322 bytes --]

Re: emergency or init=/bin/sh mode and terminal signals

[Samuel Thibault]

linux-os (Dick Johnson), le Wed 21 Jun 2006 07:53:12 -0400, a écrit :
> 
> On Mon, 19 Jun 2006, Samuel Thibault wrote:
> 
> > linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
> >> I don't think this is the correct behavior. You can't allow some
> >> terminal input to affect init. It has been the de facto standard
> >> in Unix, that the only time one should have a controlling terminal
> >> is after somebody logs in and owns something to control. If you want
> >> a controlling terminal from your emergency shell, please exec /bin/login.
> >
> > Ok, but people don't know that: they're given a shell, and wonder why on
> > hell ^C doesn't work...
> >
> > Samuel
> 
> Attached is a simple program called shell.

I already know how to write this.

The problem is not for _me_, it is for all these people that use
init=/bin/sh, and wonder why ^C doesn't work. Finding documentation on
such issue is not easy, so they'll most probably _not_ find out that
they need to use /sbin/sulogin, /bin/login, or even dig the linux-kernel
archives for your program. That's why I'm raising the issue at the
kernel level.

Samuel

Re: emergency or init=/bin/sh mode and terminal signals

[Matthias Andree]

On Tue, 20 Jun 2006, Samuel Thibault wrote:

> > Also, the above doesn't help people specifying "init=/bin/sh" on the
> > command line (as per the original post subject).  The real solution
> > is for them to specify a different init= or run/exec something to set
> > up their tty and session once logged in.
> 
> Yes. And the problem is that people usually don't know about sessions
> etc, and will just grumble "linux can't work".

Nothing prevents a distributor from providing a proper alternative boot
script to set up the session and launch the shell, and particularly
there is nothing to prevent them from adding a proper boot menu entry
for that rescue system...

-- 
Matthias Andree