mbader@cac.washington.edu (Mark Bader) (09/04/89)
Why does every xterm window I have on my screen create an entry in /usr/utmp? Then when you do a 'who', it says I'm logged in 5 times! (If I have 5 windows)? Is there an option to disable this? Thanks, Mark Bader INTERNET: mbader@cac.washington.edu Networks and Distributed Computing, UW BITNET: mbader@uwav1 3737 Brooklyn Ave. NE BELL: (206) 543-5128 Seattle, WA 98105
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (09/05/89)
Why does every xterm window I have on my screen create an entry
in /usr/utmp? Then when you do a 'who', it says I'm logged in
5 times! (If I have 5 windows)?
Is there an option to disable this?
The MIT R3 xterm contains a -ut switch (which sets the *utmpInhibit resource
to "on") to disable the adding of utmp entries.MAP@LCS.MIT.EDU (Michael A. Patton) (09/06/89)
I think what you want is two-fold. First the explanation of why it's like that. I believe it was somebody's idea about how to fix a "bug" that existed before it. I consider the "fix" worse than the original "bug". The original "bug" was that the reported idle time for a user was usually wildly wrong. The supposed "fix", causing all xterms to show up in a finger or who so that one will show no idle time, is worse because it makes it hard to determine what really is going on. I frequently have many xterms on my display and walk away to fix something, and then log in (once) from a remote machine while working there. It would be a lot to expect of most users to see a list of 15 "me"s and determine the one that's "current". Furthermore, when I am using the display, I tend to be using things other than xterm, so this isn't a "fix" anyway. I therefore use the utmpInhibit facility mentioned in a previous message (which arrived here while I was typing this up). But rather than using the -ut switch each time I invoke xterm, I make it the default (for me) by putting the following in my Xresources (or whatever name you use) file: xterm*utmpInhibit: on __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (09/06/89)
I believe it was somebody's idea about how to fix a "bug"
that existed before it. I consider the "fix" worse than the original
"bug". The original "bug" was that the reported idle time for a user
was usually wildly wrong.
Nope. The problem was that there was no way to tell whether or not somebody
was "logged onto" a given machine (i.e. running a shell on on a
pseudo-terminal that could be contacted). In particular, it made notifying
people of impending system shutdowns, etc. rather tricky.
You potentially have the same problem with all X applications, but the
terminal emulator was the 95% case (you budding session manager writers
might want to think about how "console windows" extend into the multi-machine
environment :-).stolcke@icsib6.berkeley.edu (Andreas Stolcke) (09/06/89)
In article <8909051759.AA11810@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes: >"bug". The original "bug" was that the reported idle time for a user >was usually wildly wrong. The supposed "fix", causing all xterms to >show up in a finger or who so that one will show no idle time, is >worse because it makes it hard to determine what really is going on. As with many problems there is probably no single person (or program) to blame. Part of the trouble could probably have been avoided if the people who did 'finger' some decades(?) ago had foreseen the advent of windowing workstations with the typical hundrets of 'logins' per user. Anyway, for the 'Sprite' operating system currently being developed here at Berkeley someone just hacked 'finger' to display just the login with the least idle time (unless you indicate that you want the whole story by specifying a suitable option). Looks like a sensible solution to me. Andreas ---- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
jkh@meepmeep.pcs.com (Jordan K. Hubbard) (09/06/89)
Hang on just a minute here. This is NOT a bug, or a "hack to fix finger" as most people seem to be implying. There are a number of unix utilities that expect every tty (or pty) to have a utmp entry associated with it. Write and talk, for example, require this. Without a utmp entry, users cannot write me on a given xterm (usually scribbling on my login terminal instead, which is nasty since it's the "glass tty" underlying my X session). Talk will be even more unforgiving, responding with "You don't exist, go away." It amuses me that everyone sees fit to criticise this in xterm, but never seemed to mind it in rlogind. If you think about it, they both provide the much same functionality, it's just a matter of perception. Jordan -- PCS Computer Systeme GmbH, Munich, West Germany UUCP: pyramid!pcsbst!jkh jkh@meepmeep.pcs.com EUNET: unido!pcsbst!jkh ARPA: jkh@violet.berkeley.edu or hubbard@decwrl.dec.com
pst@anise.acc.com (Paul Traina) (09/07/89)
jkh@meepmeep.pcs.com (Jordan K. Hubbard) writes: >Hang on just a minute here. This is NOT a bug, or a "hack to fix finger" >as most people seem to be implying. There are a number of unix utilities >that expect every tty (or pty) to have a utmp entry associated with it. Exactly! The bug is in finger, not xterm. However, I have fixed (to my satisfaction) said bug. I have modified finger so that on long displays (e.g. "finger -l" or "finger pst" as opposed to "finger"), it will only show one instance of the user logged in: anise-[root-1> finger Login Name TTY Idle When Office pst Paul Traina p1 1:20 Wed 09:20 963-9431 x243 pst Paul Traina p0 Wed 09:20 963-9431 x243 pst Paul Traina p2 Wed 09:20 963-9431 x243 anise-[root-2> finger pst Login name: pst In real life: Paul Traina Phone: 963-9431 x243, 569-2158 (home) Directory: /home/pst Shell: /bin/tcsh On since Sep 6 09:20:14 on ttyp2 Project: Kernel munging for fun and profit. No Plan. This allows someone to see how many times (and where) users are logged in, but doesn't give them 23000 copies of the user's plan file and all the rest of the junk that comes along with a long finger display. Here's the fix, it's not pretty, it's not efficient, but it does the job with the fewest code changes. -- in route print(), add the following two lines after the other variable definitions: register struct person *q; register long minidle; -- in routine print(), look for the for loop and add the *'ed lines: for (p = person1; p != 0; p = p->link) { if (!unquick) { quickprint(p); continue; } if (!unshort) { shortprint(p); continue; } * for (q = person1, minidle = 32767; q != 0; q = q->link) * if (!strcmp(q->name, p->name)) * minidle = min(minidle, q->idletime); * if (p->idletime > minidle) * continue; personprint(p); Instant fixed finger. -- Reclaim those words you're afraid of. There's nothing wrong with being a pervert and/or slut. We're very special people. The best. Take pride in it. -- Hank B. (but I wish I had said it first)
guy@auspex.auspex.com (Guy Harris) (09/08/89)
>Anyway, for the 'Sprite' operating system currently being developed here at >Berkeley someone just hacked 'finger' to display just the login with the least >idle time (unless you indicate that you want the whole story by specifying >a suitable option). Looks like a sensible solution to me. A better solution is the one used by the SunOS "finger" - if you're fingering the user on "/dev/console", it looks at "/dev/kbd" and "/dev/mouse" as well, and takes the minimum of the idle time of those three. This, of course, requires that there be some special files in "/dev" whose time of last access gets updated whenever your window system (X server, whatever) does a successful "read" on the input device in question. (It also hardcodes some knowledge into "finger" that ideally shouldn't be there.) The advantage of that is that it counts *all* input, even if it wasn't typed into a pseudo-tty; i.e., it counts input to all window system programs from the keyboard or mouse. Another trick done in some SunOS utilities is to recognize "utmp" entries that belong to tty emulator windows, not login sessions; a "nonuser" entry (see the "nonuser" macro in <utmp.h>) is an entry that corresponds to a pseudo-tty (i.e., is of the form "tty[pqrs]...") and has an empty "ut_host" field. Of course, this doesn't work for "xterm"s, since they fill in the "ut_host" field....
guy@auspex.auspex.com (Guy Harris) (09/08/89)
>Hang on just a minute here. This is NOT a bug, or a "hack to fix finger" >as most people seem to be implying. There are a number of unix utilities >that expect every tty (or pty) to have a utmp entry associated with it. >Write and talk, for example, require this. Without a utmp entry, users >cannot write me on a given xterm (usually scribbling on my login terminal >instead, which is nasty since it's the "glass tty" underlying my X session). That's a botch; output to the "glass tty" underlying your session should be directed to some other window - under SunOS, you can do so with the "-C" flag to "xterm" (or "shelltool" or "cmdtool" under SunView), and I think Ultrix may also have OS hooks to do the same thing. If your system doesn't have a way to do that, complain to your vendor. With that fixed, users *can* "write" you on your login terminal; the output will show up in the window in question. The annoyance is that you can't "write" back in an "xterm" of your choice and get their output in that window; however, with "talk", you can do that (since the "talk" on their side doesn't write directly to the terminal). "talk" is nicer in a network environment, anyway (and if you like "write"s user interface better, for some reason, the ideal fix is to have "write" work the way "talk" does, rather than blatting stuff directly to the user's terminal). >It amuses me that everyone sees fit to criticise this in xterm, but >never seemed to mind it in rlogind. If you think about it, they >both provide the much same functionality, it's just a matter of >perception. I think the difference people perceive may be that they view "rlogin" as really logging you in to a particular machine, while "xterm" is just popping another window up on top of an existing login session. The problem is that many UNIX utilities assume that a user will be logged onto a machine only once, or at least will only be sitting in front of one login at a time, so you can really think of multiple logins as separate. However, you may have N windows in front of you on a particular machine, but since they're all in front of you you may think of them as subsessions of a single session and not want each one to have its own "utmp" entry. With a network window session you may have M more windows in front of you, on a machine other than the one on your desk; you might also want one of those to be associated with a login session, but not the others, since they might all look like subsessions of a single session on the other machine. On top of that, you might have windows on another machine, none of which are terminal emulators and therefore cannot have "utmp" entries. The problems discussed here seem to stem from the model of the world held by said UNIX utilities breaking down in a network window system world....
jkh@meepmeep.pcs.com (Jordan K. Hubbard) (09/08/89)
In article <2422@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > > >Write and talk, for example, require this. Without a utmp entry, users > >cannot write me on a given xterm (usually scribbling on my login terminal > >instead, which is nasty since it's the "glass tty" underlying my X session). > >That's a botch; output to the "glass tty" underlying your session should >be directed to some other window - under SunOS, you can do so with the >"-C" flag to "xterm" (or "shelltool" or "cmdtool" under SunView), and I Yes, I know. Unfortunately, our vendor is US and my requests for TIOCCONS have been put on the back burner by our OS group. >I think the difference people perceive may be that they view "rlogin" as >really logging you in to a particular machine, while "xterm" is just >popping another window up on top of an existing login session. Yes, that was my point. While having multiple xterms in front of you may "feel" different than having N rlogins, it's not really that much different once you factor the demands made by unix's terminal "philosophy". Having multiple xterms comprise one logical "terminal session" might be interesting from a UI point of view, but it would be confusing. Jordan ----- PCS Computer Systeme GmbH, Munich, West Germany UUCP: pyramid!pcsbst!jkh jkh@meepmeep.pcs.com EUNET: unido!pcsbst!jkh ARPA: jkh@violet.berkeley.edu or hubbard@decwrl.dec.com
janssen@holmes (Bill Janssen) (09/12/89)
In article <JKH.89Sep6113935@meepmeep.pcs.com>, jkh@meepmeep (Jordan K. Hubbard) writes: >Hang on just a minute here. This is NOT a bug, or a "hack to fix finger" >as most people seem to be implying. There are a number of unix utilities >that expect every tty (or pty) to have a utmp entry associated with it. >[talk and write are mentioned] This is just a symptom of a larger problem, which is that a session that is based on a window system is a different kind of thing, and needs different tools and protocols. As long as we keep trying to force terminal based systems to fit into the window system world, we will have such loose ends. We would seem to need a way to register people with window systems, so that a talk daemon could pop up a talk window on the appropriate display, etc. Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304