How to disable console on serial when needed ?

Hi I want to disable console on serial when I need to use the serial port to control some serial device. But I still need to use it for log on when these serial device are not in use. So I can't just remove the console on serial support from kernel at compile time. And what I need is the ability to detach / attach console to serial port after bootup.

Is there any possible way to achieve this?

Thanks.

Raymond

Reply to
Raymond
Loading thread data ...

"console on a serial line" is simply a "getty" (or similar, often agetty or mgetty) program running connected to the serial line. These are usually controlled by the "init" program, by entries in /etc/inittab

However this does not have to be the case. First comment out any lines in /etc/inittab to prevent init from starting any "getty" process attached to the serial line. Then arrange for the getty process to be started instead by one of the initialise scripts. When you want to use the serial line, then simple kill the getty process, use the line then restart the getty when you have finished

You are confusing things.

"Console on Serial" is not required for you to be able to login on a serial line.

When the kernel starts, or needs to send diagnostic messages it does it to a "Console", usually the first virtual terminal device (VT0). "Console on Serial" makes the kernel send these messages out on a nominated serial line.

If you do have serial console enabled on the line then you have got problems. The kernel may generate output that may interfer with your application.

see above

Reply to
Jim Jackson

port

I don't know of a way to do so, but I don't know how your device works, so I can only guess. Maybe it is possible for you to create two kernel images, one with console on serial line and one without. If you don't use your serial device and want to log in, you then would need to reboot and select the other kernel image (lilo supports a serial console as well).

On the other hand, you could compile the kernel with serial console included, but later remove in the APPEND line, as in console=/dev/null or console=0,9600n8 respectively. The getty process started to actually use this console after booting can be killed or started on demand (that means only to start it from the init process if the kernel image is the one with serial console or if the append line includes the correct key word).

I think it is possible to redirect the kernel console while running and I remember having seen a C source which does the kernel call, but I couldn't find it. That way some people were able to print out kernel messages to running telnet connections (like /dev/pts/0) instead of a serial port.

On the other hand - if your memory requirements are not too tight - you could run a syslogd and a klogd who "catch" these messages and call them out onto the net (or anywhere else you want these messages, probably /dev/null). BusyBox provides these, but I'm not sure whether it will work this way.

Hope this helps, Regards, Sebastian

Reply to
Sebastian

Hi Jim

Thanks for the advise.

However , I might not get my situation clear enough. My platform is an Arm embeded board. And the /Dev/Console is not a link to first VT but with dev node major 5 minor 1

And in the inittab there are no getty to direct console to ttyS0 infact I even do not need a inittab.

instead in the kernel's main.c , there are something like :

static int init(void * unused) { lock_kernel(); do_basic_setup();

prepare_namespace();

/* * Ok, we have completed the initial bootup, and * we're essentially up and running. Get rid of the * initmem segments and start the user-mode stuff.. */ free_initmem(); unlock_kernel();

if (open("/dev/console", O_RDWR, 0) < 0) printk("Warning: unable to open an initial console.\n");

(void) dup(0); (void) dup(0); . . .

}

So , What can I do now ?

Reply to
Raymond

"Sebastian" ?ÈëÏû?ÐÂÎÅ:458b0d36$0$30327$ snipped-for-privacy@newsspool1.arcor-online.net...

Hi Sebastian

Thanks for your kindly reply. I do need to using one kernel to using for both login and drive device.

So I think I do need the ability to rederect the kernel message to some other place but still have the ability to get it back at run time lively. Thus I could not just disable it at cmdline.

The same reason for syslogd, Can I do a switch job ? I will try to read the code , Hope it's not to difficult to achieve my goal.

Thanks again.

Raymond

Reply to
Raymond

????????????:emf1al$ls2$1$ snipped-for-privacy@news.dem> >> Hi

I have explained. You have NOT understood what I said. I explained what the linux console is - it is has NOTHING to do with user logins!!! The kernel has absolutely no knowledge of how a user "logs in" - that is all handled in user space.

See

formatting link

for more info on the Serial console.

Reply to
Jim Jackson

Hello,

You are right, but that doesn't help much here. If you use a serial console, you most probably will start some getty-process or simply a shell on it. But,whether you do or nor, the kernel will print onto this console, too, and his question is simply:

"How can I completely disable / redirect the console after booting?" (If I'm wrong here, then please correct me. This is what I understood.)

You have to see it in context - it is about getty processes and whatever, but also the kernel messages are important.

Regards, Sebastian

Reply to
Sebastian

"Sebastian" ?ÈëÏû?ÐÂÎÅ:458c8c31$0$5719$ snipped-for-privacy@newsspool3.arcor-online.net...

Yes

"How can I completely disable / redirect the console input/output after I already login in a console "

This is what I mean here.

My problem is :

I using bash to atomaticly loggin the console on serial to run a certain program, So anytime I connect to the serial , I can trace the output and input commands.

I can't kill this bash after the program started, or the program will also quit. And I guess I can't using nohup to run this program, otherwise I could not check the output freely. I can only cat nohup.out

And if I loggin by telnet, I also could not check the program's output it only display on the console where the starting bash running on.

And in this program, sometime, it will control a serial device. So I hope I can redirect the output to somewhere else or disable it temply. and later , I can re-enable it and continue trace the output on serial port

I try to modify the tty_io.c to disable the userspace's output to serial port tmply, but seems doesn't work well. I believe I can achieve my aim by modify some kernel code sooner or later but I wonder , isn't there just a simple way to do it ?

Raymond

Reply to
Raymond

just picked up on this thread so maybe this was covered. To redirect the device that the kernel believes is the console use a kernel command line parameter like console=/dev/null. I use my serial console port to control a robotic arm so I cannot have kernel messages interfering with my arm control.

Reply to
noone

Hi Finally , I achieve my goal. I still use console=ttyS0 to enable serial console when booting up, and my bash will still open this console to send and receive message to serial port, so will the kernel. Then , I modify tty_io.c 's tty_write function to bypass the write request when it's aim for serial port. also for tty_read, if it's going to reading from a serial port, I make it sleep. And for the kernel's output, I modify a function in my serial.c file to bypass the write request. By this way, I can totall break the communication between console and serial port. Then I export an ioctl somewhere to enable / disable all these routine. It does work for me now, Just as if I can attach/detach the console from serial port freely. However, it's some how tricky and ugly. Hope someone got better solutions.

Raymond

Reply to
Raymond

Actually you don't (use bash to login). What happens is that the login starts up bash for you. So you may install a user (called application), which uses your application as a shell instead of bash. Look at ``man adduser'' especially the -s option. The application runs, and when it terminates, your application user is logged out.

The above is certainly simple, if it fits your bill.

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
 Click to see the full signature
Reply to
Albert van der Horst

....some kernel hackery this guy has a fixation with snipped...

Raymond

This guy has just given you a solution, he had the same problem - do you not read peoples' replies!

Jim

Reply to
Jim Jackson

Jim I know this way, actually I use it when everything goes right. But it don't fit for me when I need to debug my program. By this way , the serial console is gone forever. And I can't get the output from the program started by rcS, cause they are send to /dev/null.And I did need these output for debugging sometime.

Raymond

Reply to
Raymond

Can't you just use remote syslog for this? It's the way I do.

wimpunk.

Reply to
wimpunk

"wimpunk" ??????: snipped-for-privacy@n51g2000cwc.googlegroups.com...

Good Idea

However can it handle user program's printf output ? And Is there any document on this ? And anyway, it need a network to working on right?

Raymond

Reply to
Raymond

You could replace the printf statements to send syslog request instead, but you could also write a simple "wrapper" script that simply writes it input into syslog. I don't know if "logger" is sufficient. If not, you can take a wrapper which simply calls for logger. I don't know if you have it, but it is at least available through BusyBox.

Only the BusyBox documentation. :-)

Everything syslog is logging, is going to /var/log/messages (but you can configure syslog accordingly to your needs in /etc/syslogd.conf - BusyBox' syslogd can't), but this is also sent out to the network, if you want it to do so.

So - yes, you need a network to be able to get these messages, if you are not having a terminal to the system.

Regards, Sebastian

Reply to
Sebastian

Hello,

I just found out:

busybox provides "setconsole" and "setlogcons", which are able to redirect the system console (which runs on serial) somewhere else (like /dev/null or some telnet-pty, if desired) on-the-fly.

This might be another idea than simply to discard the console by redirecting it completely to /dev/null.

Regards, Sebastian

Reply to
Sebastian

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.