phil@BRL.MIL (Phil Dykstra) (03/29/89)
Has anyone else out there been traumatized by wall and shutdown messages while running X? On my Sun workstation, whenever a remote shutdown would occur (resulting in an rwall) the shutdown message would show up simultaneously in every X window that I had open. The console window would get two copies, and any rlogins may get a remote copy as well. Every one of these messages had three ^G beeps, etc. The end result was that the workstation would explode for 10 seconds or more util things got back under control. Here's a "fix" in case anyone else was bothered by this. If you look in Sun's /usr/include/utmp.h you find a define for nonuser() used to determine if a pty entry in utmp corresponded to a "real" user or not (i.e. someone who should get a wall message). If the host field is non-zero it assumes an rlogin and writes to that window. SunView doesn't write in the host field for local windows so this works fine there. X puts the display name in that field, and thus get a copy of the message. I put the following special version of nonuser() in the top of wall.c: /* * We define our own version of "nonuser" (in /usr/include/utmp.h) * to exclude non-console X windows. */ #undef nonuser #define nonuser(ut) (((ut).ut_host[0] == 0 \ || strcmp((ut).ut_host, ":0.0") == 0 \ || strcmp((ut).ut_host, "unix:0.0") == 0) && \ strncmp((ut).ut_line, "tty", 3) == 0 && ((ut).ut_line[3] == 'p' \ || (ut).ut_line[3] == 'q' || (ut).ut_line[3] == 'r')) You now only get a single copy of a wall message, and only to the console window. This helps a lot. Sorry, I can't help folks without source code to wall (those folks could resort to "xterm -ut" I suppose). - Phil <phil@brl.mil> uunet!brl!phil
tom@ICASE.EDU (Tom Crockett) (03/30/89)
> *Excerpts from xpert: 29-Mar-89 A "fix" for wall. Phil Dykstra@brl.mil (1719)* > If you look > in Sun's /usr/include/utmp.h you find a define for nonuser() > used to > determine if a pty entry in utmp corresponded to a "real" user or > not > (i.e. someone who should get a wall message). Can you achieve the same effect (i.e., avoiding unwanted "wall" messages) by starting xterm with the -ut option to prevent it from writing a record in utmp?
rlk@THINK.COM (Robert L. Krawitz) (03/30/89)
Date: Wed, 29 Mar 89 14:30:50 -0500 (EST) From: Tom Crockett <tom@icase.edu> Can you achieve the same effect (i.e., avoiding unwanted "wall" messages) by starting xterm with the -ut option to prevent it from writing a record in utmp? Yes. It saves my sanity. Actually, I use xterm*utmpInhibit: on ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111
jik@ATHENA.MIT.EDU (Jonathan I. Kamens) (03/30/89)
Date: Wed, 29 Mar 89 14:30:50 -0500 (EST) From: Tom Crockett <tom@icase.edu> References: <8903290045.aa18749@SPARK.BRL.MIL> Can you achieve the same effect (i.e., avoiding unwanted "wall" messages) by starting xterm with the -ut option to prevent it from writing a record in utmp? This can cause problems in certain environments that need to know when someone is logged into the machine and use utmp to figure that out. For example, at Project Athena the workstations periodically "deactivate" to flush NFS connections and do some other cleanup, and the daemon which controls deactivation decides when to deactivate by checking if there is anybody in utmp and deactivating when it is empty for five minutes. If you login to a workstation to pop up an xterm on another display, and then logout of that workstation, you may find the workstation getting deactivated right under you (This is a Bad Thing :-) if you tell xterm not to put an entry for you in utmp. Jonathan Kamens USnail: MIT Project Athena 410 Memorial Drive, No. 223F jik@Athena.MIT.EDU Cambridge, MA 02139-4318 Office: 617-253-4261 Home: 617-225-8218
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (03/30/89)
>> If you look in Sun's /usr/include/utmp.h you find a define for >> nonuser() used to determine if a pty entry in utmp corresponded to a >> "real" user or not (i.e. someone who should get a wall message). > Can you achieve the same effect (i.e., avoiding unwanted "wall" > messages) by starting xterm with the -ut option to prevent it from > writing a record in utmp? Presumably. But then lots of things don't work from xterm windows: anything depending on getlogin(), for example. A better solution, from this point of view, would be to hack xterm to give it an option to leave the host field blank in the utmp entry it writes. While we're on the subject of xterm's utmp entries....there's a bug somewhere, in that it confuses two users with the same UID: it will always put the same one into utmp, regardless of which one runs xterm. (This doesn't bother me enough to make me fix it, because there are enough other things wrong with xterm to make me write my own anyway. :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
barry@tardis.DAB.GE.COM (Barry Fishman) (04/02/89)
Phil Dykstra in <8903290045.aa18749@SPARK.BRL.MIL> noted: > If you look > in Sun's /usr/include/utmp.h you find a define for nonuser() used to > determine if a pty entry in utmp corresponded to a "real" user or not > (i.e. someone who should get a wall message). If the host field is > non-zero it assumes an rlogin and writes to that window. SunView > doesn't write in the host field for local windows so this works fine > there. X puts the display name in that field, and thus get a copy > of the message. [Followed by a contributed nonuser() macro] Creating a utmp entry with a blank host field seems to work well in our mixed computer environment. Sun console windows still get console messages from wall anyway. However, I did not find a reference to nonuser() in xterm/main.c so I assume a direct patch to main.c is needed. We have been using the following patch based on a previously posted patch to X10R4 (unfortunately I can not find the original) since X11R1. This change can not handle the recent use of ":0.0" style display references or hosts with names beginning with "unix", but I would rather present something that I have been using without problems for a long time, than something put together just before posting. The '(strncmp("unix" ...) != 0)' should probably be replaced with Phil's '(!nonuser())' to give a cleaner solution. *** clients/xterm/main.c- Sat Jan 7 13:37:16 1989 --- clients/xterm/main.c Fri Jan 13 21:11:20 1989 *************** *** 1735,1743 **** sizeof(utmp.ut_line)); (void) strncpy(utmp.ut_name, pw->pw_name, sizeof(utmp.ut_name)); ! (void) strncpy(utmp.ut_host, XDisplayString (screen->display), sizeof(utmp.ut_host)); time(&utmp.ut_time); lseek(i, (long)(tslot * sizeof(struct utmp)), 0); write(i, (char *)&utmp, sizeof(struct utmp)); --- 1739,1752 ---- sizeof(utmp.ut_line)); (void) strncpy(utmp.ut_name, pw->pw_name, sizeof(utmp.ut_name)); ! if (strncmp("unix", ! XDisplayString (screen->display), 4) != 0) ! { ! (void) strncpy(utmp.ut_host, XDisplayString (screen->display), sizeof(utmp.ut_host)); + } time(&utmp.ut_time); lseek(i, (long)(tslot * sizeof(struct utmp)), 0); write(i, (char *)&utmp, sizeof(struct utmp));
dce@stan.UUCP (David Elliott) (04/02/89)
In article <8903300011.AA29356@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: >Presumably. But then lots of things don't work from xterm windows: >anything depending on getlogin(), for example. A better solution, from >this point of view, would be to hack xterm to give it an option to >leave the host field blank in the utmp entry it writes. While all of these things solve a specific problem, it might be more useful to solve the general problem. That is, I don't see any reason for wall to send more than one message to a given user/hostname pair (where "hostname" is loosely defined to allow for xterms and remote logins to the local machine). By only sending one message to each unique user/hostname pair, this handles the case where a user runs all xterms locally, and the case where a user starts a lot of remote xterms (I use my 3/50 as an X terminal for a set of faster machines). If it doesn't show up in comp.sys.sun soon, I will post my modification to wall that does this. -- David Elliott ...!pyramid!boulder!stan!dce "Splish splash, I was rakin' in the cash" -- Eno
kovar@husc4.HARVARD.EDU (David C. Kovar) (04/03/89)
In article <717@salgado.stan.UUCP> dce@Solbourne.com (David Elliott) writes: >That is, I don't see any reason >for wall to send more than one message to a given user/hostname pair >(where "hostname" is loosely defined to allow for xterms and remote >logins to the local machine). How do you plan on determining the "correct" user/hostname pair to send the message to? When using X or SunView, I tend to start up a number of terminal windows and leave a number of them closed. Sending a message to just one window that happens to be closed is useless unless you can let the user know that he should open the window for a message. Granted, I always leave open the Console window and if you send a message to that window I'll almost always see it but that doesn't help the person who fires up two xterms on my machine and closes one of them. Which one do you talk to? -David C. Kovar
dce@stan.UUCP (David Elliott) (04/04/89)
In article <1524@husc6.harvard.edu> kovar@husc4.harvard.edu (David C. Kovar) writes: > How do you plan on determining the "correct" user/hostname pair to send >the message to? When using X or SunView, I tend to start up a number of >terminal windows and leave a number of them closed. Sending a message to >just one window that happens to be closed is useless unless you can let >the user know that he should open the window for a message. I admit that the solution is not the most correct solution. It assumes that the first entry in the utmp file for a user/hostname pair is the one to use. Even with SunView, it is possible for the console window to be obscured. The only thing that this does is to reduce the number of messages that come to your screen. For the users here, the solution I implemented has relieved a lot of tension. It would be nice if UNIX had a smarter message notification scheme than wall, especially in light of NFS and shutdown. As it stands, you risk either losing information or losing your mind. -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce
diamant@hpfclp.SDE.HP.COM (John Diamant) (04/05/89)
> How do you plan on determining the "correct" user/hostname pair to send > the message to? How does talk pick the right one? It takes the first one it finds whose tty/pty is writable. That seems like a pretty good algorithm. If you want to control it, don't make your ttys all writable. That way, you (the user) get to decide which one. John Diamant Software Engineering Systems Division Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
awm@doc.ic.ac.uk (Aled Morris) (04/07/89)
In article <9740087@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >> How do you plan on determining the "correct" user/hostname pair to send >> the message to? >How does talk pick the right one? It takes the first one it finds whose >tty/pty is writable. That seems like a pretty good algorithm. If you want >to control it, don't make your ttys all writable. That way, you (the user) >get to decide which one. What you are saying, then, is that whenever a window system terminal emulator is iconified, it should _automatically_ deny write permission to the pty it owns (kind of like "biff n" and "mesg n")? Are you listening, xterm implementors? This should be trivial, anyone care to post a patch? Aled Morris systems programmer mail: awm@doc.ic.ac.uk | Department of Computing uucp: ..!ukc!icdoc!awm | Imperial College talk: 01-589-5111x5085 | 180 Queens Gate, London SW7 2BZ
valdis@alchemy.mcs.clarkson.edu (& Kletnieks) (04/08/89)
In article <AWM.89Apr6202026@gould.doc.ic.ac.uk> awm@doc.ic.ac.uk (Aled Morris) writes: >What you are saying, then, is that whenever a window system terminal >emulator is iconified, it should _automatically_ deny write permission >to the pty it owns (kind of like "biff n" and "mesg n")? Whtat I'd like to see is an 'xterm' that when it receives a 'bell' character while iconified, would reset it's icon bitmap so window managers like 'twm' would flip it. SOmething like the 'xbiff' utility does for mail. >Are you listening, xterm implementors? >This should be trivial, anyone care to post a patch? This one isn't so trivial - anybody got a good description of how to gell if you're iconified? Flipping the bitmap is easy, but I don't wanna do it if the xterm isn't iconified. >Aled Morris >systems programmer Valdis Kletnieks Sr. Systems Programmer Clarkson University
tim@appensell.cs.wisc.edu (Tim Theisen) (04/10/89)
In article <732@salgado.stan.UUCP> dce@Solbourne.com (David Elliott) writes: >In article <1524@husc6.harvard.edu> kovar@husc4.harvard.edu (David C. Kovar) writes: >> How do you plan on determining the "correct" user/hostname pair to send >>the message to? When using X or SunView, I tend to start up a number of >>terminal windows and leave a number of them closed. Sending a message to >>just one window that happens to be closed is useless unless you can let >>the user know that he should open the window for a message. > >I admit that the solution is not the most correct solution. It >assumes that the first entry in the utmp file for a user/hostname >pair is the one to use. > >It would be nice if UNIX had a smarter message notification scheme >than wall, especially in light of NFS and shutdown. As it stands, >you risk either losing information or losing your mind. > Here at the University of Wisconsin, we have taken a different tack. When wall detects that a user is using an Xdisplay, it pops up a window and displays the message. If the window already exists, wall merely appends to it. This avoids the problem of multiple messages. It also avoids the problem of placing a message into an iconfied window. To accomplish this, we modified wall to recognize Xdisplays and post one message to each unique display. We used xmessage to display the message. We modified the xmessage program to optionally (via command line option) open a socket and display messages read from that socket. Tim Theisen Department of Computer Sciences tim@cs.wisc.edu University of Wisconsin-Madison uwvax!tim 1210 West Dayton Street (608)262-0438 Madison, WI 53706