(?) The Answer Gang (!)
By Jim Dennis, Ben Okopnik, Dan Wilder, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!


We have guidelines for asking and answering questions. Linux questions only, please.
We make no guarantees about answers, but you can be anonymous on request.
See also: The Answer Gang's Knowledge Base and the LG Search Engine


(?) suppress terminal messages of other processes

From Christoph Sandhaus

Answered By: Ben Okopnik, Thomas Adam, Mike Orr (Sluggo)

Hi TAG!

Hope you can help me, because I can't solve my problem using search-engines man-pages, faq's (linuxgazette, tldp.org, SuSE portal, ...):

Some programms send messages to any user logged in (i.e. shutdown, module error messages, ...). When using a terminal and my script is working cursor position dependent these messages really disturb!

My questions: Where do these messages come from, maybe printk (out of the kernel)? How do I suppress them?

(!) [Thomas] They come from the script doing "echo foo". Now, if they are just from scripts that you yourself invoke, you can do:
(!) [Ben] Not system messages, Thomas. Christoph is right in that regard: they do come from the kernel.
(!) [Thomas] 
some_script >/dev/null 2>&1
which means you won't see a thing. If, however, you are referring to seeing messages to your console, you can do: 
mesg n
which should suppress this. You can even use stty(1).
(!) [Ben] Nope. You can't suppress messages sent by root. And that's a Good Thing.
(in one xterm) 
ben@Fenrir:~$ mesg n
(in the second one) 
ben@Fenrir:~$ su -c 'echo Foo|wall'
(Here's what the first one looks like now) 
ben@Fenrir:~$ mesg n

Broadcast Message from ben@Fenrir.Thor
        (/dev/pts/8) at 8:52 ...

Foo

(?) Generally you are right, Ben, but: I am displaying server status and activity from my (python) script. The unwanted messages are first of all from a scsi-modul. Thus: I am interested in the message, but not in THIS terminal.

(!) [Ben] First of all, Christoph - 
---------------------------------------------------------------
To: Thomas Adam <thomas_adam16@_____.___>
Subject: Re: [TAG] suppress terminal messages of other processes
Date: Tue, 17 Feb 2004 15:07:10 +0100
Cc: Ben Okopnik <___@_________.___>
---------------------------------------------------------------
(!) [Ben] Do not take a discussion off-list without clearly stating that you're doing that, please. If you want private advice, my rates are $125/hour; I'd imagine Thomas would also charge you a consulting fee. I've added TAG back to the CC list.
I do charge, payment is in chocolate.... -- Thomas Adam
(!) [Ben] Assuming you're talking about non-critical messages, try turning off SCSI debugging in the kernel config. In an extreme case, you can tweak the module code itself (but this last one is something you'd have to do every time you update your kernel.)

(?) Are you sure there is no way to stop the messages send by root on THIS terminal?

(!) [Ben] Not unless you send all output on that terminal to "/dev/null". :) What you're proposing is still getting rid of all system messages, and I keep telling you that it's a bad idea - and thus not likely to be supported. Getting rid of the non-critical messages from one module, OK; shutting down system messages in general, bad idea.
(!) [Thomas] Absolutely a bad idea. And let's face it, having tweaked klogd( 8), one is not going to be seeing those messages until one needs to, since shutting the system down etc, is at a time when either the user is aware of what is happening, or because it is there to alert you to save your work, etc.

(?) I am your opinion.

'setterm -msglevel [n]' doesn't help: level 0 is equal to mesg y level 1: sys msg's still pass through level 8: all messages

I still belive I have to take a close look at klogd or syslog. But I doubt it will help... Next I will experience with stty.

(!) [Thomas] setterm -msglevel implies klogd

(?) I think it is in your interrest what will be my solution. This will be in the next days. If I should not post how it was going on, someone have to tell me.

(!) [Thomas] Do let us know how you get on, by all means.

(?) So far: thanks for all hints and: tell me how to reach your fee :-D Are you interesed in help at TAG?

(!) [Thomas] Yes. Look here:
https://linuxgazette.net/tag/members-faq.html
(!) [Ben] Or he could just see the messages and hit "Ctrl-L" to clear them after reading them. The screen should redraw back to the way it was before the message. I thought this would be too obvious to mention, but - maybe not.
(!) [Sluggo] Christoph, it would help if you give us some examples of exactly what messages you are seeing. That would help us narrow down which modules or kernel systems are producing them and why. See the TAG Posting FAQ, https://linuxgazette.net/tag/ask-the-gang.html especially section "Provide enough, but not too much information".
If you see something like "cannot load module char-major-10-175", it means some program is trying to access a device that is not present in the kernel. E.g., when a time synchronization program wants to access the real-time clock but you didn't compile the RTC module. The proper thing to do is to enable the module (if essential) or disable the program (if non-essential). The quick fix is to put "alias char-major-10-175 off" in /etc/modules.conf. That tells the module loader (modprobe) not to look for that module if requested. In practice, most people just use the quick fix and forget about it. After all, if the lack of that service was causing any practical problems, you would have seen it by now. See "man modules.conf" for more info.
Ctrl-L works in many Curses-based programs to redraw the screen as it should be, erasing any droppings left by other processes. It works in vim, mutt, newsreaders, etc. Although it's a longstanding Unix convention, it's not automatic, so some programs may not support it.
Going back in computer history, Ctrl-L means "form feed" (ASCII symbol FF). When a printer receives it, it ejects the page. Video consoles can't eject the page (or if they did there'd be broken glass everywhere), so they clear the screen instead. That's why shells and other line-oriented programs clear the screen when you press Ctrl-L. However, screen-oriented programs like vi decided on a different convention more useful to them: Ctrl-L redraws the screen. Line noise was a significant problem in those days, and it would sometimes cause random characters to appear on the screen. (Nowadays modems have error correction built in, so they can detect line noise.) Control-L was a convenient way to counteract that, and it's still useful when a background program invades your screen with messages.
"man ascii" shows the control codes, although it doesn't explain what the symbols mean. Most of the codes are no longer used for their original purpose anyway. Here's the original reasoning behind the codes:
https://www.cs.tut.fi/~jkorpela/chars/c0.html
Not all terminals actually responded the way they were "supposed" to. LF is supposed to go down one line but stay in the same horizontal position. That's why Windows uses CR+LF at the end of a line, because that's what old-time printers did. But VT terminals needed only LF, so that's what Unix inherited. Macintosh uses CR, perhaps attempting to redefine the code according to modern understanding. If you've ever seen a printer do "stair stepping" (starting one line where the previous one left off), that's what's happening. The computer is sending only LF, and the printer is interpreting it strictly.

(?) O.K.

Intention:

Problem:

(!) [Sluggo] One workaround would be to use a GUI window (wxPython, Tkinter, gtk, etc) for your application output. Kernel messages can't write there.

(?) Maybe I've got an idea: Doesn't the messages (i.e. from wall) arrive trough STDERR? Is there a possibility to ignore incoming messages on STDERR on a xterm?

(!) [Thomas] No, they're written to STDOUT. 
[n6tadam@laptop n6tadam]$ echo "wall" | wall 2> /dev/null

Broadcast Message from n6tadam@laptop

        (somewhere) at 15:26 ...


wall

(?) Is there a possibility to ignore incoming messages on STDERR on a xterm?

(!) [Thomas] No, since you would have to have someway of knowing the tty that your application was on -- tty(1) will tell you what it is. Again, stty might allow you, it might not...
(!) [Sluggo] Stderr is a channel a process writes out on, not a channel it receives things from. So xterm cannot receive things on stderr. It does receive things from stdin, but that's connected to the tty xterm was started from, not to the tty that xterm's display window is showing. Stdin/stdout/stderr are set by the kernel when xterm starts, and only later does xterm allocate a tty for its display window. If xterm receives something on stdin, it probably ignores it. But if it receives something on the tty connected to its window, it displays it. You can do this yourself. 
% echo "abc" >/dev/tty
abc
% tty
/dev/pts/7
% echo "abc" >/dev/pts/7
abc
% echo "abc" >/dev/pts/8
zsh: permission denied: /dev/pts/8
% w
 09:46:21 up 2 days,  9:22,  2 users,  load average: 0.06, 0.04, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
iron     tty1     -                Mon05    2days  3:15   0.03s  /bin/sh /usr/X1
iron     pts/7    :0.0             22:09    0.00s  0.98s  0.04s  w
% echo "abc" >/dev/tty1
% echo "abc" >/dev/tty7
%
(/dev/tty automatically directs to the current tty. The 'tty' command shows which tty is the current one. I got a permission error because I don't own /dev/pts/8. The first 'w' entry is the console I ran "startx" in. Writing to it didn't show up here, but it did show up in my text console. /dev/tty7 is the graphical display my X session is using, thus the one konsole was launched from, thus konsole's stdin/stdout/stderr. Writing to it didn't show up in the window, it just disappeared. In all cases, 'echo' is writing to its stdout, not to its stderr. The tty it's writing to may be somebody else's stdin or stderr, but that depends on how that other somebody is configured.)
I use konsole, which is kind of a super xterm from KDE. Each konsole has multiple views (like screen), but sometimes I launch a second konsole from the first so I can keep two sets of views separate. For instance, one set of views for my personal stuff, and another set for work stuff (which are all su'd to another user). The second konsole writes all sorts of undesired debugging information on stderr, which stomps over the view I launched it from -- similar to the problem you're having. So I start it with "konsole 2>/dev/null" to suppress those messages. But that only works if you do it to the process that's writing the messages. You can't do that to the kernel, to a driver or a daemon, since you don't have control over their stdin/stdout/stderr.

(?) I have had some experiences and it seems there is nothing I can do. And "stty" (Hello Thomas!) isn't the answer either. There was no way to switch off stdin.

I tryed to redirect /dev/pts/X (sorry about this stupid attempt :-D) and I think you can imagin what happened: "operation not permitted"

Thanks a LOT to all of you! I stop off here with all experiments. But I've learned a lot and maybe next week I'll join TAG.

As I pointed out above, anyone is welcome to join TAG, just as long as you read the following first:
https://linuxgazette.net/tag/members-faq.html -- Thomas Adam

This page edited and maintained by the Editors of Linux Gazette
Copyright © its authors, 2004
Published in issue 100 of Linux Gazette March 2004
HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

[ Table Of Contents ][ Answer Guy Current Index ] greetings   Meet the Gang   1   2   3   4   5   6   7 [ Index of Past Answers ]