Bug 71368 - gnome-terminal "update utmp/wtmp" option doesn't work when not using gdm
Summary: gnome-terminal "update utmp/wtmp" option doesn't work when not using gdm
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vte
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
: 75408 (view as bug list)
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
Reported: 2002-08-12 19:19 UTC by Nathan G. Grennan
Modified: 2008-05-01 15:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-09 08:57:08 UTC

Attachments (Terms of Use)

Description Nathan G. Grennan 2002-08-12 19:19:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020712

Description of problem:
Gnome-terminal doesn't register with "w" when using startx. Even when run login
shell and Update utmp/wtmp.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. login as user
2. startx
3. start gnome-terminal
4. run w

Actual Results:  no entry for the gnome-terminal

Expected Results:  Entry for the gnome-terminal

Additional info:

Limbo beta2

Work when using gdm

Comment 1 Nathan G. Grennan 2002-08-12 19:21:57 UTC
xterm entries do appear in "w" under startx

Comment 2 Havoc Pennington 2002-08-12 19:56:09 UTC
it's an option, look in edit->current profile. xterm should be consistent 
I'll agree. I believe the right default is not to update utmp/wtmp when 
opening a new terminal (and this is consistent with us running bash as a login
shell in the Xsession script).

Reassigning to XFree to toggle the xterm default.

Comment 3 Nathan G. Grennan 2002-08-12 20:37:17 UTC
Hmm, I think you misunderstood Havoc. It does set utmp/wtmp entries with run
login shell and Update utmp/wtmp checked if running X through gdm. I want it to
do the same with startx. I like to see the entries for terminal windows. In gdm
it only makes one utmp/wtmp entry for my four gnome-terminals even if I disable
factory. Personally I would prefer it made an entry for each terminal window.

Comment 4 Mike A. Harris 2002-08-12 20:49:24 UTC
Non login shells are subshells, however they are invoked, and should not
show up in utmp/wtmp.  Only true login shells should show up.

I make no claim as to wether or not there is a problem or not with xterm,
however we do not support xterm, we only provide it for convenience.  If
there is a problem with xterm in this regard, please report it to XFree86.org
upstream and/or Thomas Dickey the xterm maintainer.  If they believe
that xterm needs fixing, they'll do so, and we'll pick up the changes
during the next XFree86 release (4.3.0).

Comment 5 Havoc Pennington 2002-08-12 20:52:59 UTC
Here is how it is supposed to work: 

 - by default, opening a terminal window never updates utmp/wtmp
 - logging in via gdm should update utmp/wtmp because it runs
   bash as a login shell
 - logging in via startx should NOT update utmp/wtmp (because it was already 
   updated when you logged in to the console)

Basically utmp/wtmp gets updated whenever you have to log in (type your
password, etc.).

If you toggle the pref in gnome-terminal, then utmp/wtmp should update 
whenever you open a terminal. But not by default.

This is AFAIK how it currently behaves. Which part is behaving incorrectly?

I don't know what xterm currently does, but it should default to NOT updating

Comment 6 Nathan G. Grennan 2002-08-12 21:08:15 UTC
You aren't exactly clear. At first you say by default it never should. Does that
mean both in gdm and startx? Then you say if you st the preference in
gnome-terminal it should, but the preference shouldn't be the default. So the
preference have no effect in startx, but work through gdm?

Comment 7 Havoc Pennington 2002-08-12 21:25:08 UTC
startx/gdm has no relationship to what the terminal should do. The terminal
should never update utmp/wtmp, because it's assumed that you logged in on the
console then used startx, or logged in via gdm. Either way, you already logged in. 
So the terminal should not record an additional login.

Comment 8 Nathan G. Grennan 2002-08-12 22:08:17 UTC
Talking to you is like talking to a wall. You still haven't answered my
questions and seem to be ignoring the bug.

Comment 9 Havoc Pennington 2002-08-12 22:19:39 UTC
Well if you want to be rude about it, I won't bother to try and help. I've done
my best to explain my view on the matter and how I think it currently works. I
don't understand what questions remain for you; maybe try rephrasing your questions.

I do not think the behavior of the terminal app should be different for gdm vs.
startx. AFAIK the terminal defaults to the behavior which is correct for both, 
which is to NOT log to utmp/wtmp. What is the bug? What are you saying does not

The bug title is "terminal does not register with w when using startx" - it is
not supposed to register with w, as I've explained. You can toggle a preference
if you want it to register. Are you arguing that it should register with w by
default? If so you will have to present an argument to that effect.
Are you saying the preference doesn't work? If so that's a bug, but 
has nothing to do with startx.

Comment 10 Mike A. Harris 2002-08-13 00:55:26 UTC
Indeed.  utmp/wtmp are for registering logins.  A login being either
initiated via gdm/xdm/kdm, ssh/telnet, local console login, or invoking
a login manually.

A terminal shell such as xterm, et al. being ran from inside an X session,
wether that X session was initiated by "startx" or by gdm/kdm/xdm does not
matter.  The login process is what gets logged to utmp/wtmp, not the
creation of a subshell.

I really do not see what the problem is here other than end user
misunderstanding of how utmp/wtmp semantics are supposed to work, and
wanting them to work some other way than they are designed and intended
to work.

Unless I'm presented with a real world bug, which I agree is a real world
bug, discussing it in any manner rude or otherwise is pointless.

Please contact the XFree86 team if you think xterm is buggy and should
be modified to do something it does not do right now.

Can we put this dead horse to rest now?

I could modify the %files list in XFree86.spec to solve the problem
another way perhaps:

# Unsupported software, now disabled

Comment 11 Nathan G. Grennan 2002-08-13 01:09:23 UTC
yes, the preference doesn't work in startx, that is The Bug, but it does in gdm.
I would have thought it was clear that was what I was trying to say already. I
understand that it isn't supposed to work the way I want by default. But it is
supposed to be an option via the preference and they preference doesn't work in
a certain situtation, startx.

Comment 12 Havoc Pennington 2002-08-13 02:02:39 UTC
Oh, no, I did not understand what you were trying to say. You are saying the
preference doesn't do anything. Sorry about that.

Comment 13 Mike A. Harris 2002-08-16 10:55:38 UTC
Reassigning to hp for gdm preference thingie

Comment 14 David Woodhouse 2002-09-11 08:43:59 UTC
utmp is also there for keeping track of live terminals. If it doesn't work, then
talk requests, finger, etc all stop working.

Despite having configured gnome-terminal months ago to always update wtmp/utmp,
it seems to have forgotten this configuration on upgrading. I've turned on the
'Run command as a login shell' and 'update utmp/wtmp records when command is
launched' preferences, exited gnome-terminal completely and restarted it, but
it's still not updating utmp and wtmp as requested. 

I logged in with gdm, if it's relevant; which I suspect it's not.

Comment 15 Havoc Pennington 2002-10-08 13:39:57 UTC
*** Bug 75408 has been marked as a duplicate of this bug. ***

Comment 16 Havoc Pennington 2003-01-08 05:30:39 UTC
I'm pretty sure utmp/wtmp are working (and that gnome-terminal has the right
defaults for this now) but if not we should notice prior to release.

Comment 17 Nalin Dahyabhai 2003-02-08 00:15:13 UTC
Should be fixed now.

Comment 18 David Woodhouse 2003-02-09 08:57:08 UTC
Sorry, yes -- it's fixed in Phoebe.

Note You need to log in before you can comment on or make changes to this bug.