Looks pretty trivial, but opinions on this subject may vary.
Comments?
J?rn
--
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf
Some userspace applications rely on the assumption that fd's 0, 1 and
2 are always open and function as raw stdin, stdout and stderr,
respectively.
With no console registered, init get's called without those fd's
already open. Arguably, init should know better, handle that case and
fix things before forking other processed. But what about
init=/bin/bash? Ok, bash could be fixed as well, as could...
Instead, this patch opens /dev/null when /dev/console doesn't work.
It swallows all output and doesn't give much input, but programs can
handle that just fine.
Signed-off-by: J?rn Engel <[email protected]>
---
main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletion(-)
--- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
+++ linux-2.6.8cow/init/main.c 2004-10-05 20:46:08.000000000 +0200
@@ -695,8 +695,11 @@
system_state = SYSTEM_RUNNING;
numa_default_policy();
- if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
+ if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
printk("Warning: unable to open an initial console.\n");
+ if (open("/dev/null", O_RDWR, 0) == 0)
+ printk(" Falling back to /dev/null.\n");
+ }
(void) sys_dup(0);
(void) sys_dup(0);
On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> Looks pretty trivial, but opinions on this subject may vary.
> Comments?
There's a related problem. /sbin/hotplug. I keep seeing odd failures
from /sbin/hotplug scripts which go away when I ensure that fd0,1,2 are
directed at something real.
It's rather annoying because it currently means that, when my PCMCIA net
interface on the firewall comes up, the IPv4 configuration works fine
but IPv6 configuration falls dead on its nose without any explaination
why.
And, like I say, redirecting fd0,1,2 fixes it.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Tue, Oct 05, 2004 at 09:27:12PM +0100, Russell King wrote:
> On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> > Looks pretty trivial, but opinions on this subject may vary.
> > Comments?
>
> There's a related problem. /sbin/hotplug. I keep seeing odd failures
> from /sbin/hotplug scripts which go away when I ensure that fd0,1,2 are
> directed at something real.
Which scripts cause this problem?
> It's rather annoying because it currently means that, when my PCMCIA net
> interface on the firewall comes up, the IPv4 configuration works fine
> but IPv6 configuration falls dead on its nose without any explaination
> why.
>
> And, like I say, redirecting fd0,1,2 fixes it.
Redirecting it in the script itself? Or in the kernel like this patch?
thanks,
greg k-h
On Tue, Oct 05, 2004 at 02:06:59PM -0700, Greg KH wrote:
> On Tue, Oct 05, 2004 at 09:27:12PM +0100, Russell King wrote:
> > On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> > > Looks pretty trivial, but opinions on this subject may vary.
> > > Comments?
> >
> > There's a related problem. /sbin/hotplug. I keep seeing odd failures
> > from /sbin/hotplug scripts which go away when I ensure that fd0,1,2 are
> > directed at something real.
>
> Which scripts cause this problem?
I have no idea. Somewhere in the depths of the Red Hat networking
scripts. There's multiple of them calling multiple other programs
and it's impossible to debug what's going on. All I know is that
IPv6 doesn't get configured if fd0,1,2 are closed, but does if they're
open.
It could be a script, or some other program. There's no way to tell.
> > It's rather annoying because it currently means that, when my PCMCIA net
> > interface on the firewall comes up, the IPv4 configuration works fine
> > but IPv6 configuration falls dead on its nose without any explaination
> > why.
> >
> > And, like I say, redirecting fd0,1,2 fixes it.
>
> Redirecting it in the script itself? Or in the kernel like this patch?
I'm redirecting them in the /sbin/hotplug script to something sane,
but I think the kernel itself should be directing these three fd's
to somewhere whenever it invokes any user program, even if it is
/dev/null.
I think Alan disagrees with me, but I think the history that these
types of problems _keep_ cropping up over and over is proof enough
that it's necessary for sane userspace.
(Another example which is happening _now_: having /sbin/init die over
a suspend/resume cycle because you have no system console on your
embedded device isn't nice.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
> More computing sins are committed in the name of efficiency (without
> necessarily achieving it) than for any other single reason - including
> blind stupidity.
> -- W. A. Wulf
>
> Some userspace applications rely on the assumption that fd's 0, 1 and
> 2 are always open and function as raw stdin, stdout and stderr,
> respectively.
>
> With no console registered, init get's called without those fd's
> already open. Arguably, init should know better, handle that case and
> fix things before forking other processed. But what about
> init=/bin/bash? Ok, bash could be fixed as well, as could...
>
> Instead, this patch opens /dev/null when /dev/console doesn't work.
> It swallows all output and doesn't give much input, but programs can
> handle that just fine.
>
> Signed-off-by: J?rn Engel <[email protected]>
> ---
>
> main.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletion(-)
>
> --- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
> +++ linux-2.6.8cow/init/main.c 2004-10-05 20:46:08.000000000 +0200
> @@ -695,8 +695,11 @@
> system_state = SYSTEM_RUNNING;
> numa_default_policy();
>
> - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
> + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
> printk("Warning: unable to open an initial console.\n");
> + if (open("/dev/null", O_RDWR, 0) == 0)
> + printk(" Falling back to /dev/null.\n");
> + }
What will happen if /dev is totally empty?
--
vda
On Tue, Oct 05, 2004 at 09:27:12PM +0100, Russell King wrote:
> On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> > Looks pretty trivial, but opinions on this subject may vary.
> > Comments?
>
> There's a related problem. /sbin/hotplug. I keep seeing odd failures
> from /sbin/hotplug scripts which go away when I ensure that fd0,1,2 are
> directed at something real.
Yes. In principle, user space must be able to handle the case
where no fds 0,1,2 are available. For example in mount.c:
while((fd = open("/dev/null", O_RDWR)) == 0 || fd == 1) ;
if (fd > 2)
close(fd);
or so.
Andries
J?rn Engel <[email protected]> wrote:
>
> --- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
> +++ linux-2.6.8cow/init/main.c 2004-10-05 20:46:08.000000000 +0200
> @@ -695,8 +695,11 @@
> system_state = SYSTEM_RUNNING;
> numa_default_policy();
>
> - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
> + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
> printk("Warning: unable to open an initial console.\n");
> + if (open("/dev/null", O_RDWR, 0) == 0)
> + printk(" Falling back to /dev/null.\n");
> + }
>
> (void) sys_dup(0);
> (void) sys_dup(0);
/usr/src/25/init/main.c:183: undefined reference to `open'
I assume this worked for you because it's against 2.6.8 and we were still
supporting kernel syscalls then.
Please always test patches against current kernels.
I'll fix it up.
On Wed, Oct 06, 2004 at 12:58:57AM +0300, Denis Vlasenko wrote:
> > + if (open("/dev/null", O_RDWR, 0) == 0)
> > + printk(" Falling back to /dev/null.\n");
> > + }
>
> What will happen if /dev is totally empty?
... Which is the most probable reason causing this trouble.
I've long wondered why the kernel could not open the /dev/console fds itself
since they are character devices, so handled by the kernel internally. It
should be possible to bypass the file-system access and get the fds anyway.
Or we might need some tricks such as populate rootfs with 'console' before
mounting root, open it, remove the entry while keeping the fd for use after
the real root is mounted. This way, it would not be the real /dev/console
which would be passed to init, so it would never even have to exist.
Comments ?
Willy
On Wed, Oct 06, 2004 at 12:36:21AM +0200, Andries Brouwer wrote:
> On Tue, Oct 05, 2004 at 09:27:12PM +0100, Russell King wrote:
> > There's a related problem. /sbin/hotplug. I keep seeing odd failures
> > from /sbin/hotplug scripts which go away when I ensure that fd0,1,2 are
> > directed at something real.
>
> Yes. In principle, user space must be able to handle the case
> where no fds 0,1,2 are available. For example in mount.c:
>
> while((fd = open("/dev/null", O_RDWR)) == 0 || fd == 1) ;
> if (fd > 2)
> close(fd);
>
> or so.
That's all well and good in theory, but do you really think that every
single userspace program handles this case correctly?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Wed, 6 Oct 2004, Willy Tarreau wrote:
> On Wed, Oct 06, 2004 at 12:58:57AM +0300, Denis Vlasenko wrote:
> > > + if (open("/dev/null", O_RDWR, 0) == 0)
> > > + printk(" Falling back to /dev/null.\n");
> > > + }
> >
> > What will happen if /dev is totally empty?
>
> ... Which is the most probable reason causing this trouble.
Indeed, but there are other known cases.
Some debug methods use register_console() to get their print routines
registered. If people forget to say e.g. `console=tty0' afterwards, the debug
console without the real device cannot be opened through /dev/console, and they
get a mysterious error. Usually /dev/console _is_ present in the root fs.
Perhaps a better fix is to modify the /dev/console demux code to fall back to
`/dev/null' (quotes to indicate this has nothing to do with a present /dev/null
on your root fs or ramdisk, but that it's the virtual null device) if the
struct console corresponding to /dev/console is not an existing tty device.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 6 October 2004 10:43:52 +0200, Geert Uytterhoeven wrote:
> On Wed, 6 Oct 2004, Willy Tarreau wrote:
> > On Wed, Oct 06, 2004 at 12:58:57AM +0300, Denis Vlasenko wrote:
> > > > + if (open("/dev/null", O_RDWR, 0) == 0)
> > > > + printk(" Falling back to /dev/null.\n");
> > > > + }
> > >
> > > What will happen if /dev is totally empty?
> >
> > ... Which is the most probable reason causing this trouble.
I have no idea about the probability, but in the one case I worry
about, a console is explicitly disabled because it is not wanted.
/dev does exist and is populated.
> Some debug methods use register_console() to get their print routines
> registered. If people forget to say e.g. `console=tty0' afterwards, the debug
> console without the real device cannot be opened through /dev/console, and they
> get a mysterious error. Usually /dev/console _is_ present in the root fs.
Yes, I thought about doing things at a different level as well. If
there really is no console, shouldn't /dev/console have the same
behavious as /dev/null?
Point is that above patch is simpler and empiria didn't give me a
reason to worry about anything else.
J?rn
--
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
On Tue, 5 October 2004 16:30:52 -0700, Andrew Morton wrote:
>
> /usr/src/25/init/main.c:183: undefined reference to `open'
>
> I assume this worked for you because it's against 2.6.8 and we were still
> supporting kernel syscalls then.
>
> Please always test patches against current kernels.
Or keep the brown paperbag nearby. Doh!
> I'll fix it up.
Thanks.
J?rn
--
Public Domain - Free as in Beer
General Public - Free as in Speech
BSD License - Free as in Enterprise
Shared Source - Free as in "Work will make you..."
On Wed, 6 Oct 2004, [iso-8859-1] J?rn Engel wrote:
> On Wed, 6 October 2004 10:43:52 +0200, Geert Uytterhoeven wrote:
> > On Wed, 6 Oct 2004, Willy Tarreau wrote:
> > > On Wed, Oct 06, 2004 at 12:58:57AM +0300, Denis Vlasenko wrote:
> > > > > + if (open("/dev/null", O_RDWR, 0) == 0)
> > > > > + printk(" Falling back to /dev/null.\n");
> > > > > + }
> > > >
> > > > What will happen if /dev is totally empty?
> > >
> > > ... Which is the most probable reason causing this trouble.
>
> I have no idea about the probability, but in the one case I worry
> about, a console is explicitly disabled because it is not wanted.
> /dev does exist and is populated.
>
> > Some debug methods use register_console() to get their print routines
> > registered. If people forget to say e.g. `console=tty0' afterwards, the debug
> > console without the real device cannot be opened through /dev/console, and they
> > get a mysterious error. Usually /dev/console _is_ present in the root fs.
>
> Yes, I thought about doing things at a different level as well. If
> there really is no console, shouldn't /dev/console have the same
> behavious as /dev/null?
>
> Point is that above patch is simpler and empiria didn't give me a
> reason to worry about anything else.
I'll give you another reason :-)
If I do have multiple active struct consoles registered (e.g. normal tty0 or
ttyS0 and a debug console without a real tty), and the /dev/console demux
thinks the debug console is the real one (the one opened if you open
/dev/console), printk() messages will appear on both active consoles, but
/dev/console cannot be opened.
To avoid this problem, the /dev/console demux should walk the list of active
consoles until it finds one that can be opened, or fall back to /dev/null if
none is found.
Does that sound reasonable?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 6 October 2004 15:07:05 +0200, Geert Uytterhoeven wrote:
> On Wed, 6 Oct 2004, [iso-8859-1] J?rn Engel wrote:
> >
> > Point is that above patch is simpler and empiria didn't give me a
> > reason to worry about anything else.
>
> I'll give you another reason :-)
>
> If I do have multiple active struct consoles registered (e.g. normal tty0 or
> ttyS0 and a debug console without a real tty), and the /dev/console demux
> thinks the debug console is the real one (the one opened if you open
> /dev/console), printk() messages will appear on both active consoles, but
> /dev/console cannot be opened.
>
> To avoid this problem, the /dev/console demux should walk the list of active
> consoles until it finds one that can be opened, or fall back to /dev/null if
> none is found.
>
> Does that sound reasonable?
Not to me, no. But I was wrong before.
Having no console at all is a valid design. It used to cause
problems, my patch fixes them. A command-line option like
"console=/dev/null" doesn't fix it because it doesn't do what it
appears to do at first glance, so the patch is needed.
Having a non-working console, esp. for debug, is a rather odd design.
My approach would be to either explicitly tell the kernel to use the
other as default console via "console=/dev/ttyS0" or not have the
debug thing in the kernel in the first place. Either way, no patch is
needed.
Worse, a kernel patch would paper over what is an underlying problem
in my book. Fix the first problem, don't live with it as good as
possible.
Is this reasonable?
J?rn
--
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague.
-- Edsger W. Dijkstra
On Wed, 6 Oct 2004, [iso-8859-1] J?rn Engel wrote:
> On Wed, 6 October 2004 15:07:05 +0200, Geert Uytterhoeven wrote:
> > On Wed, 6 Oct 2004, [iso-8859-1] J?rn Engel wrote:
> > > Point is that above patch is simpler and empiria didn't give me a
> > > reason to worry about anything else.
> >
> > I'll give you another reason :-)
> >
> > If I do have multiple active struct consoles registered (e.g. normal tty0 or
> > ttyS0 and a debug console without a real tty), and the /dev/console demux
> > thinks the debug console is the real one (the one opened if you open
> > /dev/console), printk() messages will appear on both active consoles, but
> > /dev/console cannot be opened.
> >
> > To avoid this problem, the /dev/console demux should walk the list of active
> > consoles until it finds one that can be opened, or fall back to /dev/null if
> > none is found.
> >
> > Does that sound reasonable?
>
> Not to me, no. But I was wrong before.
>
> Having no console at all is a valid design. It used to cause
One problem is that `console' means multiple things:
1. The output device for printk() (multiple consoles are allowed, cfr.
multiple console= kernel parameters and debug-only consoles)
2. The tty (both input and output) for /sbin/init (only one instance, cfr.
the last console= kernel parameter)
I suggested to change the logic for 2 not to use the last console= kernel
parameter if it turns out not to support input (cfr. the return value of struct
console.device()), but try the other registered struct consoles.
> problems, my patch fixes them. A command-line option like
> "console=/dev/null" doesn't fix it because it doesn't do what it
> appears to do at first glance, so the patch is needed.
Indeed. Because the /dev/null driver doesn't call register_console().
It could be made to work that way (`console=null'), though, but make sure to
register your null-console _first_.
But I think it's simpler to just check console->device() and take appropriate
actions.
> Having a non-working console, esp. for debug, is a rather odd design.
> My approach would be to either explicitly tell the kernel to use the
> other as default console via "console=/dev/ttyS0" or not have the
> debug thing in the kernel in the first place. Either way, no patch is
> needed.
It was not `designed' to be that way. But due to how `the console' (nr. 2 from
above) works, registration order matters. If people make the mistake (or just
forget) to say `console=ttyS0', a debug console registered later causes
problems.
And the reason the debug consoles (read: capturers) use register_console() is
to avoid code duplication.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 6 October 2004 15:55:52 +0200, Geert Uytterhoeven wrote:
>
> One problem is that `console' means multiple things:
> 1. The output device for printk() (multiple consoles are allowed, cfr.
> multiple console= kernel parameters and debug-only consoles)
> 2. The tty (both input and output) for /sbin/init (only one instance, cfr.
> the last console= kernel parameter)
Correct. It may be nice have a seperate logic for 1. 'console' is a
good name for 2., so I would keep that. But then again, I don't care
enough to write a patch.
> I suggested to change the logic for 2 not to use the last console= kernel
> parameter if it turns out not to support input (cfr. the return value of struct
> console.device()), but try the other registered struct consoles.
>
> [...]
>
> > Having a non-working console, esp. for debug, is a rather odd design.
> > My approach would be to either explicitly tell the kernel to use the
> > other as default console via "console=/dev/ttyS0" or not have the
> > debug thing in the kernel in the first place. Either way, no patch is
> > needed.
>
> It was not `designed' to be that way. But due to how `the console' (nr. 2 from
> above) works, registration order matters. If people make the mistake (or just
> forget) to say `console=ttyS0', a debug console registered later causes
> problems.
>
> And the reason the debug consoles (read: capturers) use register_console() is
> to avoid code duplication.
Which is fair. So we end up with two devices claiming to be a valid
console, but one of them makes people unhappy. Are you certain that
*everone* wants to have 'ttyS0' as default console and not 'debug'?
Taking the last one registered is basically random. If people care
enough, they should explicitly state things on the command line.
Taking the last with input support (or the last, if none support
input) adds some policy. If people disagree with the kernel policy,
they should explicitly state things...
Policy inside the kernel sounds like a bad idea. People can already
get what they want, if they... Policy will help some people with
similar taste, but people with different taste can "argue" against it
and someone has to play judge - not my cup of tea.
J?rn
--
Premature optimization is the root of all evil.
-- Donald Knuth
On Wed, 6 Oct 2004, [iso-8859-1] J?rn Engel wrote:
> On Wed, 6 October 2004 15:55:52 +0200, Geert Uytterhoeven wrote:
> > > Having a non-working console, esp. for debug, is a rather odd design.
> > > My approach would be to either explicitly tell the kernel to use the
> > > other as default console via "console=/dev/ttyS0" or not have the
> > > debug thing in the kernel in the first place. Either way, no patch is
> > > needed.
> >
> > It was not `designed' to be that way. But due to how `the console' (nr. 2 from
> > above) works, registration order matters. If people make the mistake (or just
> > forget) to say `console=ttyS0', a debug console registered later causes
> > problems.
> >
> > And the reason the debug consoles (read: capturers) use register_console() is
> > to avoid code duplication.
>
> Which is fair. So we end up with two devices claiming to be a valid
> console, but one of them makes people unhappy. Are you certain that
> *everone* wants to have 'ttyS0' as default console and not 'debug'?
Ehrm, what do you mean with `default' console?
If you mean `console as defined under nr.2', yes, you want the console that
does do input.
> Taking the last one registered is basically random. If people care
> enough, they should explicitly state things on the command line.
No, it's not. It's explicitly mentioned in the docs: if you use multiple
`console=', all of them get output, but input comes from the last one.
> Taking the last with input support (or the last, if none support
> input) adds some policy. If people disagree with the kernel policy,
> they should explicitly state things...
Calling it `policy' may be a bit too strict...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 6 October 2004 16:23:27 +0200, Geert Uytterhoeven wrote:
>
> Ehrm, what do you mean with `default' console?
>
> If you mean `console as defined under nr.2',
correct
> yes, you want the console that
> does do input.
*I* don't always do. Remember how this thread got started? ;)
> > Taking the last one registered is basically random. If people care
> > enough, they should explicitly state things on the command line.
>
> No, it's not. It's explicitly mentioned in the docs: if you use multiple
> `console=', all of them get output, but input comes from the last one.
Ah, true. I was barking up the "the was no 'console=' option, take
the default" tree. Just started looking at the console code a few
days ago.
Still, it currently is the official interface and allows the user to
do the right thing. It doesn't exactly make it hard to do the wrong
thing, though. On Rusty's scale it should rate as 7 or 8.
http://www.ozlabs.com/~rusty/ols-2003-keynote/img48.html
Can you think of a simple way to improve things?
J?rn
--
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham
On Wed, 6 Oct 2004, [iso-8859-1] J?rn Engel wrote:
> On Wed, 6 October 2004 16:23:27 +0200, Geert Uytterhoeven wrote:
> > Ehrm, what do you mean with `default' console?
> >
> > If you mean `console as defined under nr.2',
> correct
> > yes, you want the console that
> > does do input.
>
> *I* don't always do. Remember how this thread got started? ;)
OK, so you want /dev/console to fall back to /dev/null, right?
> > > Taking the last one registered is basically random. If people care
> > > enough, they should explicitly state things on the command line.
> >
> > No, it's not. It's explicitly mentioned in the docs: if you use multiple
> > `console=', all of them get output, but input comes from the last one.
>
> Ah, true. I was barking up the "the was no 'console=' option, take
> the default" tree. Just started looking at the console code a few
> days ago.
Well, you're right that if the user specifies _no_ console= option at all, the
`first one in the linked list' will be used, which is the last one registered.
Usually (read: if enabled) tty0 registers automatically, and it's the only one.
Saying e.g. `console=ttyS0' causes the serial console to register itself (at
the head of the list).
Saying e.g. `console=tty0' afterwards causes the VT console to move back to the
head of the list.
So _if_ there are multiple struct consoles activated, order (read: policy) does
matter. But usually there's only one, and all others are explicitly to be
enabled with console=.
Anyway, I should cook up a patch so the /dev/console demux walks the list if
the one at the head of the list doesn't do input (read: it has no associated
tty struct).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 6 October 2004 17:36:17 +0200, Geert Uytterhoeven wrote:
>
> OK, so you want /dev/console to fall back to /dev/null, right?
In short, yes. I want fds 0, 1 and 2 to be open for any userspace
process on startup. That's partly init's job, partly also the
kernel's job. And /dev/null is a sane fallback.
> Anyway, I should cook up a patch so the /dev/console demux walks the list if
> the one at the head of the list doesn't do input (read: it has no associated
> tty struct).
Good.
J?rn
--
A victorious army first wins and then seeks battle.
-- Sun Tzu
On Maw, 2004-10-05 at 22:13, Russell King wrote:
> I'm redirecting them in the /sbin/hotplug script to something sane,
> but I think the kernel itself should be directing these three fd's
> to somewhere whenever it invokes any user program, even if it is
> /dev/null.
Someone should yes. There are lots of fascinating things happen when
hotplug opens a system file, it gets assigned fd 2 and then we write to
stderr.
> I think Alan disagrees with me, but I think the history that these
> types of problems _keep_ cropping up over and over is proof enough
> that it's necessary for sane userspace.
Userspace to userspace execution is quite precisely defined. What
happens for kernel->userspace isn't so I have no problem with the kernel
attaching hotplug to the system console.
On Wed, Oct 06, 2004 at 04:00:23PM +0100, Alan Cox wrote:
> On Maw, 2004-10-05 at 22:13, Russell King wrote:
> > I'm redirecting them in the /sbin/hotplug script to something sane,
> > but I think the kernel itself should be directing these three fd's
> > to somewhere whenever it invokes any user program, even if it is
> > /dev/null.
>
> Someone should yes. There are lots of fascinating things happen when
> hotplug opens a system file, it gets assigned fd 2 and then we write to
> stderr.
Good point. So, should we do it in the kernel, in call_usermodehelper,
so that all users of this function get it correct, or should I do it in
userspace, in the /sbin/hotplug program?
Any opinions?
thanks,
greg k-h
On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> --- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
> +++ linux-2.6.8cow/init/main.c 2004-10-05 20:46:08.000000000 +0200
> @@ -695,8 +695,11 @@
> system_state = SYSTEM_RUNNING;
> numa_default_policy();
>
> - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
> + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
> printk("Warning: unable to open an initial console.\n");
> + if (open("/dev/null", O_RDWR, 0) == 0)
> + printk(" Falling back to /dev/null.\n");
> + }
Your printk() calls need the proper KERN_* level.
And what happens if you can't open /dev/null? (hint, udev enabled boxes
usually do not have a /dev/null this early in the boot process). Does
this mean we should add a /dev/null to the initramfs image, like the
/dev/console node we currently have there?
thanks,
greg k-h
On Wed, 6 October 2004 10:41:08 -0700, Greg KH wrote:
>
> Good point. So, should we do it in the kernel, in call_usermodehelper,
> so that all users of this function get it correct, or should I do it in
> userspace, in the /sbin/hotplug program?
>
> Any opinions?
Kernel.
Same reasoning as before, if someone comes along and creates a "much
better" /sbin/hotplug which doesn't handle it, things will break
again.
J?rn
--
Data dominates. If you've chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.
-- Rob Pike
On Wed, 6 October 2004 10:38:23 -0700, Greg KH wrote:
> On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> > --- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
> > +++ linux-2.6.8cow/init/main.c 2004-10-05 20:46:08.000000000 +0200
> > @@ -695,8 +695,11 @@
> > system_state = SYSTEM_RUNNING;
> > numa_default_policy();
> >
> > - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
> > + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
> > printk("Warning: unable to open an initial console.\n");
> > + if (open("/dev/null", O_RDWR, 0) == 0)
> > + printk(" Falling back to /dev/null.\n");
> > + }
>
> Your printk() calls need the proper KERN_* level.
As does the original one. Which one would you like for both?
> And what happens if you can't open /dev/null?
Same as before.
> (hint, udev enabled boxes
> usually do not have a /dev/null this early in the boot process). Does
> this mean we should add a /dev/null to the initramfs image, like the
> /dev/console node we currently have there?
Yes, that would fix the case. Is this a problem?
J?rn
--
When people work hard for you for a pat on the back, you've got
to give them that pat.
-- Robert Heinlein
On Wed, Oct 06, 2004 at 10:41:08AM -0700, Greg KH wrote:
> Good point. So, should we do it in the kernel, in call_usermodehelper,
> so that all users of this function get it correct, or should I do it in
> userspace, in the /sbin/hotplug program?
The doctrine of defensive programming will teach you to write
/sbin/hotplug so that it can cope with such things.
(But I do not object at all to also doing it in the kernel.
Some would call it "papering over user space bugs", but one might
as well call it "making the system more robust".)
Andries
On Wed, Oct 06, 2004 at 08:04:21PM +0200, J?rn Engel wrote:
> On Wed, 6 October 2004 10:38:23 -0700, Greg KH wrote:
> > On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> > > --- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
> > > +++ linux-2.6.8cow/init/main.c 2004-10-05 20:46:08.000000000 +0200
> > > @@ -695,8 +695,11 @@
> > > system_state = SYSTEM_RUNNING;
> > > numa_default_policy();
> > >
> > > - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
> > > + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
> > > printk("Warning: unable to open an initial console.\n");
> > > + if (open("/dev/null", O_RDWR, 0) == 0)
> > > + printk(" Falling back to /dev/null.\n");
> > > + }
> >
> > Your printk() calls need the proper KERN_* level.
>
> As does the original one. Which one would you like for both?
KERN_WARNING perhaps?
> > And what happens if you can't open /dev/null?
>
> Same as before.
>
> > (hint, udev enabled boxes
> > usually do not have a /dev/null this early in the boot process). Does
> > this mean we should add a /dev/null to the initramfs image, like the
> > /dev/console node we currently have there?
>
> Yes, that would fix the case. Is this a problem?
I don't have a problem with doing that.
thanks,
greg k-h
On Wed, Oct 06, 2004 at 08:01:45PM +0200, J?rn Engel wrote:
> On Wed, 6 October 2004 10:41:08 -0700, Greg KH wrote:
> >
> > Good point. So, should we do it in the kernel, in call_usermodehelper,
> > so that all users of this function get it correct, or should I do it in
> > userspace, in the /sbin/hotplug program?
> >
> > Any opinions?
>
> Kernel.
>
> Same reasoning as before, if someone comes along and creates a "much
> better" /sbin/hotplug which doesn't handle it, things will break
> again.
Ok, I buy it :)
Care to send a patch to do this?
thanks,
greg k-h
* J?rn Engel ([email protected]) wrote:
> On Wed, 6 October 2004 10:41:08 -0700, Greg KH wrote:
> >
> > Good point. So, should we do it in the kernel, in call_usermodehelper,
> > so that all users of this function get it correct, or should I do it in
> > userspace, in the /sbin/hotplug program?
> >
> > Any opinions?
>
> Kernel.
I agree. There's code in the kernel doing that already, but IIRC, it's
only in SELinux.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Tue, 2004-10-05 at 20:52 +0200, Jörn Engel wrote:
>
> main.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletion(-)
>
> --- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
> +++ linux-2.6.8cow/init/main.c 2004-10-05 20:46:08.000000000 +0200
> @@ -695,8 +695,11 @@
> system_state = SYSTEM_RUNNING;
> numa_default_policy();
>
> - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
> + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
> printk("Warning: unable to open an initial console.\n");
> + if (open("/dev/null", O_RDWR, 0) == 0)
> + printk(" Falling back to /dev/null.\n");
> + }
BTW. What happens if /dev/console or /dev/null are regular files?
I don't see any check for this. I didn't think Linux imposed any
namespace layout/ownership/permission requirements.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/scaramanga.asc | gpg --import
On Wed, 6 October 2004 19:37:30 +0100, Gianni Tedesco wrote:
>
> BTW. What happens if /dev/console or /dev/null are regular files?
Interesting point. Any readers (init, some/all of it's children) will
read until one reaches EOF, all writers will flood it 'til it's full.
If there was an IOUAC (international obfuscated unix abuse contest),
you could use this for IPC, maybe.
> I don't see any check for this. I didn't think Linux imposed any
> namespace layout/ownership/permission requirements.
Anyone able to turn /dev/console into a regular file can already do
much worse things. Don't think it's a security issue.
J?rn
--
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra
On Wed, 6 October 2004 11:18:36 -0700, Greg KH wrote:
>
> Care to send a patch to do this?
Below. Never tried udev and/or hotplug, never even looked at the code
yet. So you better don't trust me.
J?rn
--
A defeated army first battles and then seeks victory.
-- Sun Tzu
Open the standard fds 0, 1 and 2 for usermode helpers. Or at least
try to do so.
Signed-off-by: J?rn Engel <[email protected]>
---
kmod.c | 7 +++++++
1 files changed, 7 insertions(+)
--- linux-2.6.8cow/kernel/kmod.c~hotplug 2004-09-04 22:59:14.000000000 +0200
+++ linux-2.6.8cow/kernel/kmod.c 2004-10-06 21:16:16.000000000 +0200
@@ -166,6 +166,13 @@
/* We can run anywhere, unlike our parent keventd(). */
set_cpus_allowed(current, CPU_MASK_ALL);
+ /* Try to open either /dev/console or /dev/null for fds 0, 1 and 2 */
+ if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
+ (void) sys_open("/dev/null", O_RDWR, 0);
+
+ (void) sys_dup(0);
+ (void) sys_dup(0);
+
retval = -EPERM;
if (current->fs->root)
retval = execve(sub_info->path, sub_info->argv,sub_info->envp);
On Wed, 6 October 2004 11:19:58 -0700, Greg KH wrote:
> On Wed, Oct 06, 2004 at 08:04:21PM +0200, J?rn Engel wrote:
> > On Wed, 6 October 2004 10:38:23 -0700, Greg KH wrote:
> > >
> > > Your printk() calls need the proper KERN_* level.
> >
> > As does the original one. Which one would you like for both?
>
> KERN_WARNING perhaps?
As in the patch below?
> > > usually do not have a /dev/null this early in the boot process). Does
> > > this mean we should add a /dev/null to the initramfs image, like the
> > > /dev/console node we currently have there?
> >
> > Yes, that would fix the case. Is this a problem?
>
> I don't have a problem with doing that.
Then please do so. :)
J?rn
--
Premature optimization is the root of all evil.
-- Donald Knuth
Some userspace applications rely on the assumption that fd's 0, 1 and
2 are always open and function as raw stdin, stdout and stderr,
respectively.
With no console registered, init get's called without those fd's
already open. Arguably, init should know better, handle that case and
fix things before forking other processed. But what about
init=/bin/bash? Ok, bash could be fixed as well, as could...
Instead, this patch opens /dev/null when /dev/console doesn't work.
It swallows all output and doesn't give much input, but programs can
handle that just fine.
Signed-off-by: J?rn Engel <[email protected]>
---
main.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
--- linux-2.6.8cow/init/main.c~console 2004-10-05 20:46:40.000000000 +0200
+++ linux-2.6.8cow/init/main.c 2004-10-06 21:14:43.000000000 +0200
@@ -695,8 +695,13 @@
system_state = SYSTEM_RUNNING;
numa_default_policy();
- if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
- printk("Warning: unable to open an initial console.\n");
+ if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) {
+ printk(KERN_WARNING
+ "Warning: unable to open an initial console.\n");
+ if (sys_open("/dev/null", O_RDWR, 0) == 0)
+ printk(KERN_WARNING
+ " Falling back to /dev/null.\n");
+ }
(void) sys_dup(0);
(void) sys_dup(0);
On Wed, Oct 06, 2004 at 10:41:08AM -0700, Greg KH wrote:
> On Wed, Oct 06, 2004 at 04:00:23PM +0100, Alan Cox wrote:
> > On Maw, 2004-10-05 at 22:13, Russell King wrote:
> > > I'm redirecting them in the /sbin/hotplug script to something sane,
> > > but I think the kernel itself should be directing these three fd's
> > > to somewhere whenever it invokes any user program, even if it is
> > > /dev/null.
> >
> > Someone should yes. There are lots of fascinating things happen when
> > hotplug opens a system file, it gets assigned fd 2 and then we write to
> > stderr.
>
> Good point. So, should we do it in the kernel, in call_usermodehelper,
> so that all users of this function get it correct, or should I do it in
> userspace, in the /sbin/hotplug program?
If we're going to use /dev/console, how about we re-use what Jorn has for
opening the console when starting init(8) ?
(Appologies Jorn - I'm not on a machine which allows me to type foreign
characters, or even cut'n'paste atm.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Mer, 2004-10-06 at 18:41, Greg KH wrote:
> Good point. So, should we do it in the kernel, in call_usermodehelper,
> so that all users of this function get it correct, or should I do it in
> userspace, in the /sbin/hotplug program?
>
> Any opinions?
Userspace is more flexible. What does the kernel do if it can't figure
out what to open as fd 0, 1, 2. Either it explodes or asks user space.
While /sbin/hotplug can mknod itself a private /dev/null and
/dev/console in an emergency.
On Wed, Oct 06, 2004 at 08:18:54PM +0100, Alan Cox wrote:
> On Mer, 2004-10-06 at 18:41, Greg KH wrote:
> > Good point. So, should we do it in the kernel, in call_usermodehelper,
> > so that all users of this function get it correct, or should I do it in
> > userspace, in the /sbin/hotplug program?
> >
> > Any opinions?
>
> Userspace is more flexible. What does the kernel do if it can't figure
> out what to open as fd 0, 1, 2. Either it explodes or asks user space.
> While /sbin/hotplug can mknod itself a private /dev/null and
> /dev/console in an emergency.
Ok, then anyone with some serious bash-foo care to send me a patch for
the existing /sbin/hotplug file that causes it to handle this properly?
thanks,
greg k-h
On Mer, 2004-10-06 at 21:54, Greg KH wrote:
> Ok, then anyone with some serious bash-foo care to send me a patch for
> the existing /sbin/hotplug file that causes it to handle this properly?
Something like
#!/bin/sh
(
Everything you had before
) <>/dev/console 2>&1
On Wed, 2004-10-06 at 21:23 +0200, Jörn Engel wrote:
> On Wed, 6 October 2004 11:19:58 -0700, Greg KH wrote:
> > On Wed, Oct 06, 2004 at 08:04:21PM +0200, J?rn Engel wrote:
> > > On Wed, 6 October 2004 10:38:23 -0700, Greg KH wrote:
> > > >
> > > > Your printk() calls need the proper KERN_* level.
> > >
> > > As does the original one. Which one would you like for both?
> >
> > KERN_WARNING perhaps?
>
> As in the patch below?
>
> > > > usually do not have a /dev/null this early in the boot process). Does
> > > > this mean we should add a /dev/null to the initramfs image, like the
> > > > /dev/console node we currently have there?
> > >
> > > Yes, that would fix the case. Is this a problem?
> >
> > I don't have a problem with doing that.
>
> Then please do so. :)
Take your pick:
This depends on the initramfs from file patch that is in the mm tree:
--- usr/initramfs_list.orig 2004-10-06 15:49:40.838941640 -0600
+++ usr/initramfs_list 2004-10-06 15:48:51.076506680 -0600
@@ -2,4 +2,5 @@
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
+nod /dev/null 0666 0 0 c 1 3
dir /root 0700 0 0
This is the old, hard-coded list built in to gen_init_cpio:
--- usr/gen_init_cpio.c.orig 2004-10-06 15:53:21.538390224 -0600
+++ usr/gen_init_cpio.c 2004-10-06 15:53:36.454122688 -0600
@@ -215,6 +215,7 @@
{
cpio_mkdir("/dev", 0755, 0, 0);
cpio_mknod("/dev/console", 0600, 0, 0, 'c', 5, 1);
+ cpio_mknod("/dev/null", 0600, 0, 0, 'c', 1, 3);
cpio_mkdir("/root", 0700, 0, 0);
cpio_trailer();
On Wed, Oct 06, 2004 at 09:29:44PM +0100, Alan Cox wrote:
> On Mer, 2004-10-06 at 21:54, Greg KH wrote:
> > Ok, then anyone with some serious bash-foo care to send me a patch for
> > the existing /sbin/hotplug file that causes it to handle this properly?
>
> Something like
>
> #!/bin/sh
> (
> Everything you had before
> ) <>/dev/console 2>&1
What about:
#!/bin/sh
exec </dev/null >/dev/console 2>&1 || exec </dev/null >/dev/null 2>&1
... original stuff ...
?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Wed, 6 Oct 2004, Thayne Harbaugh wrote:
> On Wed, 2004-10-06 at 21:23 +0200, J?rn Engel wrote:
> > On Wed, 6 October 2004 11:19:58 -0700, Greg KH wrote:
> > > On Wed, Oct 06, 2004 at 08:04:21PM +0200, J?rn Engel wrote:
> > > > On Wed, 6 October 2004 10:38:23 -0700, Greg KH wrote:
> > > > >
> > > > > Your printk() calls need the proper KERN_* level.
> > > >
> > > > As does the original one. Which one would you like for both?
> > >
> > > KERN_WARNING perhaps?
> >
> > As in the patch below?
> >
> > > > > usually do not have a /dev/null this early in the boot process). Does
> > > > > this mean we should add a /dev/null to the initramfs image, like the
> > > > > /dev/console node we currently have there?
> > > >
> > > > Yes, that would fix the case. Is this a problem?
> > >
> > > I don't have a problem with doing that.
> >
> > Then please do so. :)
>
> Take your pick:
>
> This depends on the initramfs from file patch that is in the mm tree:
[ patch deleted ]
This fixes the standard initamfs. But it still allows you to have a root file
system without /dev/console or /dev/null.
What about letting the kernel open the console without going through
/dev/console? Since the kernel knows /dev/console is the device with major 5
minor 1, why can't it just open (5, 1)? Then we don't need a /dev/console node,
and things will never break.
Same for /dev/null as a fallback.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Oct 07, 2004 at 10:18:51AM +0200, Geert Uytterhoeven wrote:
> What about letting the kernel open the console without going through
> /dev/console? Since the kernel knows /dev/console is the device with major 5
> minor 1, why can't it just open (5, 1)? Then we don't need a /dev/console node,
> and things will never break.
Famous last words. What about the case where you don't have a console
device registered (eg in the case of an embedded device) ? Currently,
opening /dev/console fails in that circumstance.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Thu, 7 Oct 2004, Russell King wrote:
> On Thu, Oct 07, 2004 at 10:18:51AM +0200, Geert Uytterhoeven wrote:
> > What about letting the kernel open the console without going through
> > /dev/console? Since the kernel knows /dev/console is the device with major 5
> > minor 1, why can't it just open (5, 1)? Then we don't need a /dev/console node,
> > and things will never break.
>
> Famous last words. What about the case where you don't have a console
> device registered (eg in the case of an embedded device) ? Currently,
> opening /dev/console fails in that circumstance.
Why didn't you quote the next line I wrote?
| Same for /dev/null as a fallback.
which answers your question :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 06 Oct 2004 21:29:44 BST, Alan Cox said:
> On Mer, 2004-10-06 at 21:54, Greg KH wrote:
> > Ok, then anyone with some serious bash-foo care to send me a patch for
> > the existing /sbin/hotplug file that causes it to handle this properly?
Greg - Unless you're willing to trust that /dev/ is in something of a sane
state (basically, you're willing to take a leap of faith that /dev/console
and/or /dev/null exist and are references to character devices with the
correct major,minor pair, it's a somewhat doomed quest.
> Something like
>
> #!/bin/sh
> (
> Everything you had before
> ) <>/dev/console 2>&1
That should be '< /dev/console > /dev/console 2>&1' - what you have will open
fd0 on /dev/console for read/write, then point fd2 at wherever fd1 happened to
be pointing. And even that version isn't totally correct - the man page for sh
specifically says: "A failure to open or create a file causes the redirection
to fail." So if /dev/console is borked due to a bad console= kernel
boot parameter, we'll *still* be flying along with a borked stderr.
A *slightly* better version would be:
#!/bin/sh
# First, check if it's even there - we could mknod it but it's
# not safe if /dev is totally scrogged or on a R/O filesystem.
if [ ! -c /dev/console ]; then
exit 999
# not-really-safe mknod magic
if [ -e /dev/console ]; then
/bin/rm -f /dev/console
fi
/sbin/mknod /dev/console c 5 1
# end not-really-safe code
fi
# Next, try redirecting each of 0,1,2 to /dev/console - if
# we redirect and fail, try to use /dev/null instead.
exec < /dev/console
if [ ! /dev/fd/0 -ef /dev/console ]; then
exec < /dev/null
if [ ! /dev/fd/0 -ef /dev/null ]; then
exit 998;
fi
fi
exec > /dev/console
if [ ! /dev/fd/1 -ef /dev/console ]; then
exec > /dev/null
if [ ! /dev/fd/1 -ef /dev/null ]; then
exit 998;
fi
fi
exec 2> /dev/console
if [ ! /dev/fd/2 -ef /dev/console ]; then
exec 2> /dev/null
if [ ! /dev/fd/2 -ef /dev/null ]; then
exit 998
fi
fi
# Everything you had before
This would be a lot shorter as:
for filedesc in 0 1 2; do
exec $filedesc<> /dev/console
if [ ! /dev/fd/$filedesc -ef /dev/console ]; then
exec $filedesc> /dev/null
if [ ! /dev/fd/$filedesc -ef /dev/null ]; then
exit 998
fi
fi
done
But that leaves fd 0-2 in read/write rather than unidirectional.
The reason the rm/mknod isn't really safe is because if either of them
generate an error message, they'll go wherever fd2 is pointing (which is
the problem we're trying to solve, and a major bootstrap problem).
Note that this *still* assumes that at least one of /dev/console or /dev/null
is sane enough to use - if /dev/console won't open (due to a borked 'console='
on the boot line, or whatever), and /dev/null is on a R/O filesystem and has
gotten mangled and is now a regular file, you're still screwed....
On Tue, 2004-10-05 21:27:12 +0100, Russell King <[email protected]>
wrote in message <[email protected]>:
> On Tue, Oct 05, 2004 at 08:52:14PM +0200, J?rn Engel wrote:
> It's rather annoying because it currently means that, when my PCMCIA net
> interface on the firewall comes up, the IPv4 configuration works fine
> but IPv6 configuration falls dead on its nose without any explaination
> why.
>
> And, like I say, redirecting fd0,1,2 fixes it.
I see this at home, too, but here, I use radvd to distribute a working
IPv6 configuration. However, the root cause seems to be different: this
card (some cheap NE2k clone driven by pcnet_cs) seems to ignore the
router advertisements. If I 'ifconfig eth0 promisc' the interface right
after insertion (before the timer for interface IPv6-auto-configutation
expires), it works as expected...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[email protected] wrote:
>
> The reason the rm/mknod isn't really safe is because if either of them
> generate an error message, they'll go wherever fd2 is pointing (which is
> the problem we're trying to solve, and a major bootstrap problem).
Just close them before you start:
exec <&- >&- 2>&-
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt