redirecting console Output to /dev/null
Sven Geggus
I惴 using an embedded system with serial console enabled.
This works fine, when the serial Port is not needed otherwise.
But now I have to use the serial port for another purpose, so I was wondering
if it is possible to use /dev/null instead of /dev/ttyS0 as console device.
I don愒 have a graphic board either, so I would be glad to have no console
at all. Is this possible?
Thanks for hints
Sven
--
wenn ping auf localhost nicht funktioniert, solltest Du zuerst TCP/IP
de- und neuinstallieren.
(Mario Arndt in de.comm.protocols.tcp-ip)
/me is giggls@ircnet, http://geggus.net/sven/ on the Web
Frieder Ferlemann
maybe the command nohup does it for you.
(Be shure to check that standard err output
does not hurt you)
Bye
Frieder
Sven Geggus wrote:
>
> Hi there,
>
> I´m using an embedded system with serial console enabled.
>
> This works fine, when the serial Port is not needed otherwise.
>
> But now I have to use the serial port for another purpose, so I was wondering
> if it is possible to use /dev/null instead of /dev/ttyS0 as console device.
>
> I don´t have a graphic board either, so I would be glad to have no console
Frieder Ferlemann
sorry, my first response was a no-brainer.
I should have read your question more carefully.
>> --
>> wenn ping auf localhost nicht funktioniert, solltest Du zuerst TCP/IP
>> de- und neuinstallieren.
Looking at your signature I feel I should
correct my answer promptly:)
Bye
Frieder
Pete Zaitcev
> if it is possible to use /dev/null instead of /dev/ttyS0 as console device.
There are several sources of console messages.
1. Kernel outputs to whatever console is registered, with printk().
2. init and its children have output bound to /dev/console by the
way of normal opening.
You can redirect #2 to /dev/null, but not the #1. For that, you
better hack drivers/char/serial.c. Actually, it is easy NOT to
register any console, in that case internal buffers will simply
overflow, but I am not sure how harmless it is. Another easy
option is to issue a console log level ioctl in the same way
as klogd -c N does. That would cut off all console messages.
-- Pete
Sven Geggus
> Another easy option is to issue a console log level ioctl in the same way
> as klogd -c N does. That would cut off all console messages.
This sounds good, as I don't know if there are other drivers in the Kernel
than mine which may use printk. Actually the one i've written myself also
uses printk ;) Would I need to dig in the klogd sources for the actual
number of this ioctl command?
I would need something which prevents printk output as well as output of
stuff like "login" which I assume just opens /dev/console for logging.
Would it be possible to replace the character device by /dev/null?
Also I remember somebody talking about a Kernel patch which eliminates all
printk messages completely does anybody else know about this?
Sven
--
"Thinking of using NT for your critical apps?
Isn't there enough suffering in the world?"
(Advertisement of Sun Microsystems in Wall Street Journal)
Anders Larsen
>
> Also I remember somebody talking about a Kernel patch which eliminates all
> printk messages completely does anybody else know about this?
Hi,
simply pass the parameter "console=null" to the kernel at boot-up,
and everything should be quiet.
From /usr/src/linux/Documentation/serial-console.txt:
"You can specify multiple console= options on the kernel command line.
Output will appear on all of them. The last device will be used when
you open /dev/console. So, for example:
console=ttyS1,9600 console=tty0
defines that opening /dev/console will get you the current foreground
virtual console, and kernel messages will appear on both the VGA
console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
Note that you can only define one console per device type (serial, video)."
HTH
cheers
Anders
Sven Geggus
> simply pass the parameter "console=null" to the kernel at boot-up,
> and everything should be quiet.
This does not work for me!
> The last device will be used when
> you open /dev/console.
I suppose this has to be a valid console "null" is not valid in this case.
Sven
--
"In the land of the brave and the free, we defend our freedom
with the GNU GPL" (Richard M. Stallman on www.gnu.org)
Sven Geggus
> There are several sources of console messages.
> 1. Kernel outputs to whatever console is registered, with printk().
I catched these using the following C Code:
#include <stdio.h>
#include <sys/klog.h>
int main() {
klogctl(6, NULL, 0);
return(0);
}
> 2. init and its children have output bound to /dev/console by the
> way of normal opening.
These are still there ...
I suppose I would need to patch /bin/login to make it shut up.
Probably I will also be able to link /dev/console to /dev/null
I will try to do this right now.
Sven
--
"We just typed make"
(Stephen Lambrigh, Director of Server Product Marketing at Informix
about porting their Database to Linux)
Anders Larsen
> Anders Larsen <a...@alarsen.net> wrote:
>
>> simply pass the parameter "console=null" to the kernel at boot-up,
>> and everything should be quiet.
>
> This does not work for me!
Why not? What happens?
>> The last device will be used when
>> you open /dev/console.
>
> I suppose this has to be a valid console "null" is not valid in this
> case.
As you can see in the snippet from Serial-console.txt, the name
supplied to "console=" is a device name without the "/dev/" prefix,
so "console=null" _is_ valid.
The system I work with has serial console enabled in the kernel.
With "console=ttyS0,9600" I get the normal boot messages;
with "console=null" the kernel keeps quiet and ttyS0 is free
for the applications to use.
In another posting you mention that you get a login prompt on
the serial console.
Check the entries in /etc/inittab (look for "respawn") and comment
out the lines referencing the serial port.
HTH
cheers
Anders
Pete Zaitcev
> > case.
>
> As you can see in the snippet from Serial-console.txt, the name
> supplied to "console=" is a device name without the "/dev/" prefix,
> so "console=null" _is_ valid.
Look at the code in kernel/printk.c. The mapping of console names
is done by looking it up in the list of registered consoles,
anchored in console_drivers. /dev/null is located on disk
and has NOTHING to do with the parameter of console= argument.
For heaven's sake, the code is out there for you guys to inspect.
-- Pete
Pete Zaitcev
> > way of normal opening.
>
Good idea, we all used to do it. The current fashion is
to make /dev/console a character device 5,1. In that case
everything that is written to it goes through kernel
console path and is controllable with kernel arguments
and ioctls. Do not run getty on such console though -
your shell won't have job control.
-- Pete
Sven Geggus
> I catched these using the following C Code:
> #include <stdio.h>
> #include <sys/klog.h>
> int main() {
> klogctl(6, NULL, 0);
> return(0);
> }
> Probably I will also be able to link /dev/console to /dev/null
Just for the sake of completeness. This works fine, as does the avove
C-Code.
So using the above C-Programm and something like this as /dev/console:
crw------- 1 root root 1, 3 26. Aug 21:26 /dev/console
seems to shut up the console altogether.
This way I can still watch the Kernel Bootmessages on the serial console
before using the C-Program to prepare the console for alternative usage.
One has to make shure, that Bootmessages do not confuse the attached device,
but that´s not the case in my setup.
Sven
--
.. this message has been created using an outdated OS (UNIX-like) with an
outdated mail- or newsreader (text-only) :-P
Anders Larsen
>> > I suppose this has to be a valid console "null" is not valid in
>> > this case.
>>
>> As you can see in the snippet from Serial-console.txt, the name
>> supplied to "console=" is a device name without the "/dev/" prefix,
>> so "console=null" _is_ valid.
>
> Look at the code in kernel/printk.c. The mapping of console names is
> done by looking it up in the list of registered consoles, anchored in
> console_drivers. /dev/null is located on disk and has NOTHING to do
> with the parameter of console= argument.
Passing the "console=<dev>" parameter to the kernel controls the
registering of consoles into console_drivers, in that it prevents
devices that do _not_ match the parameter list from registering.
It follows that passing "console=null" (as I suggested) prevents
*any* device from registering as a console, achieving the desired
effect.
You're right that it doesn't actually *redirect* console output
to /dev/null; it tells the kernel that there *isn't* any console
at all (the result is the same, though).
cheers
Anders