Bug 1280724 - No longer updates utmp/wtmp login records
Summary: No longer updates utmp/wtmp login records
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: vte291
Version: 23
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Debarshi Ray
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1466993 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-12 03:26 UTC by Luigi Cantoni
Modified: 2017-07-03 13:20 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-21 00:02:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 747046 0 Normal RESOLVED cleanup pty.c 2020-06-24 07:24:31 UTC

Description Luigi Cantoni 2015-11-12 03:26:52 UTC
Description of problem:
Who format/information displayed changed
who am i return "blank"

Version-Release number of selected component (if applicable):
who --help does not display a version number etc

How reproducible:
Always currently displaying error

Steps to Reproduce:
1. execute who once booted

Actual results:
who am i gives no output
who always returns a a single user attached to tty1
e.g.
$ who am i
$ who
fred      tty1         Nov 12 10:42 (:0)

Expected results:
$ who am i
fred      pts/0        Nov 12 10:42 (:0)
who
fred      pts/0        Nov 12 10:42 (:0)
fred      pts/1        Nov 12 10:42 (:0)

NOTE: fred has more than one gnome terminal session active in both cases

Additional info:
Who is working correctly in Fedora 21
Update was done from Fedora21->22->23
I cannot report in fedora 22 has the issue as I went updated without testing fedora 22 other than some simple botts and look OK.

NOTE: my belief is that likely that utmp or wtmp has some sort of issue.
I have reset the wtmp files (utmp at bootup anyway) and problem is still there.

If this behaviour is intended it is quite a dramatic change to the who output.

Comment 1 Ondrej Vasik 2015-11-12 08:56:20 UTC
There was no change in "who" recently. Command "who" just interprets information from utmp file. It seems this file is somehow broken on your machine "thanks to" update. I'll reassign to systemd for now - as this is owner of /var/run/utmp...

Comment 2 Tim Waugh 2015-11-12 10:38:11 UTC
Don't you mean "whoami" (no spaces)?

Comment 3 Jan Synacek 2015-11-12 11:57:53 UTC
$ who am i
This never worked, unless there's a file name "am" with the correct format. The "whoami" command still works the same, AFAICT.

On F21:
# who
root     tty1         2015-11-12 12:47

# rpm -q coreutils systemd
coreutils-8.22-22.fc21.x86_64
systemd-216-25.fc21.x86_64


On F23:
# who
root     tty3         2015-11-12 12:55

# rpm -q coreutils systemd
coreutils-8.24-4.fc23.x86_64
systemd-222-8.fc23.x86_64

Comment 4 Pádraig Brady 2015-11-12 12:19:12 UTC
`who am i` is equivalent to `who -m`

If you `ssh localhost` then the tty is set appropriately in utmp and it works.
From a standard xterm though there is a mismatch between `tty` and the entries in utmp. I.E. the xterm entries are not there. I see /var/run/utmp is writable by the utmp group, so perhaps there are permissions tweaks needed?

Comment 5 Jaroslav Škarvada 2015-11-12 14:57:48 UTC
(In reply to Pádraig Brady from comment #4)
> `who am i` is equivalent to `who -m`
>
'who ANYSTRING' is alias for 'who -m', but it is mostly used as 'who am i'

> If you `ssh localhost` then the tty is set appropriately in utmp and it
> works.
> From a standard xterm though there is a mismatch between `tty` and the
> entries in utmp. I.E. the xterm entries are not there. I see /var/run/utmp
> is writable by the utmp group, so perhaps there are permissions tweaks
> needed?

The /run/utmp should has 0664 rights and root:utmp owner.

IIRC xterm uses libutempter to add records for its PTYs and it works correctly for me on f23.

There are terminals and other SW that do not care about utmp, e.g. Midnight Commandeer is good example. From its subshell 'who -m' or 'who am i' returns nothing. This is because it doesn't add the record for its PTY. RFE can be filed upstream.

I also checked gnome-terminal and it seems 'who -m' worked in f22, but stopped working in f23. I don't know what they use for utmp handling thus reassigning to gnome-terminal.

Comment 6 Jaroslav Škarvada 2015-11-12 14:59:48 UTC
Reproducer:

Open gnome-terminal:
$ utmpdump /run/utmp 

Current result:
No record in utmp for the gnome-terminal

Expected result:
Record for the ghome-terminal in utmp

This worked on f22, stopped working on f23.

Comment 7 Jaroslav Škarvada 2015-11-12 15:21:52 UTC
(In reply to Jaroslav Škarvada from comment #5)
> I don't know what they use for utmp handling thus reassigning to gnome-terminal.

IMHO they previously used gnome-pty-helper from the vte package to manipulate utmp.

Comment 8 Jaroslav Škarvada 2015-11-12 15:24:33 UTC
(In reply to Jaroslav Škarvada from comment #7)
> (In reply to Jaroslav Škarvada from comment #5)
> > I don't know what they use for utmp handling thus reassigning to gnome-terminal.
> 
> IMHO they previously used gnome-pty-helper from the vte package to
> manipulate utmp.

This doesn't seem to be vte bug, because it works OK from pure vte.

Comment 9 Debarshi Ray 2015-11-12 16:41:56 UTC
(In reply to Jaroslav Škarvada from comment #7)
> (In reply to Jaroslav Škarvada from comment #5)
> > I don't know what they use for utmp handling thus reassigning to gnome-terminal.
> 
> IMHO they previously used gnome-pty-helper from the vte package to
> manipulate utmp.

gnome-pty-helper has been dropped:

commit 299c700c743c7d5dfd14e3b3a21417d9e9f35818
Author: Christian Persch <chpe>
Date:   Mon Mar 30 20:04:40 2015 +0200

    pty: Remove PTY helper
    
    It's only used for the obsolete [uw]tmp logging.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=747046

Comment 10 Luigi Cantoni 2015-11-25 03:54:08 UTC
I have recently updated my x86_64 machine also to Fedora 23 and who is only partly broken in that version.
Who with no arguments appears to still work.
While "who am i" does not display the full information like it used to (only the user name).
who -m which used to work now returns "blank". So it fails completely.

I am not sure if the code detailed above is partly put back in the x86_64 version or maybe it was not fully taken out in the first place. Either way it is wrong.

i686 still fails as described above. I am updating daily (approx) but not beta versions only normal releases.

NOTE: someone mention before "whoami" as opposed to "who am i" whomai is a separate program altogether which is designed to just give the user name (I think). The current "who am i" on x86_64 now returns what "whoami" does.

Comment 11 Jaroslav Škarvada 2015-11-25 11:49:10 UTC
(In reply to Luigi Cantoni from comment #10)
> I have recently updated my x86_64 machine also to Fedora 23 and who is only
> partly broken in that version.
> Who with no arguments appears to still work.
> While "who am i" does not display the full information like it used to (only
> the user name).
> who -m which used to work now returns "blank". So it fails completely.
>
who is not broken, the problem is that there is no terminal record in wtmp if running from gnome-terminal. Or are you running from different terminal? So far I have known only about gnome-terminal which is broken.
 
> I am not sure if the code detailed above is partly put back in the x86_64
> version or maybe it was not fully taken out in the first place. Either way
> it is wrong.
>
I am still able to reproduce the problem on any arch.
gnome-terminal-3.18.2-1.fc23.x86_64

Which version of which terminal do you use?

> i686 still fails as described above. I am updating daily (approx) but not
> beta versions only normal releases.
> 
> NOTE: someone mention before "whoami" as opposed to "who am i" whomai is a
> separate program altogether which is designed to just give the user name (I
> think). The current "who am i" on x86_64 now returns what "whoami" does.
whoami != "who am I", they are completely different programs doing completely different things. "who am I" lookups wtmp records and gets the result from there. If there is no record, it cannot display anything. On the other hand, the whoami displays the effective ID of itself, i.e. of the process who spawned it, there is no wtmp lookup used by whoami (AFAIK).

Comment 12 Luigi Cantoni 2015-11-26 00:19:59 UTC
Yes "who" is the symptom not the cause. Sorry its just that "who" was how I found it.
The two current versions of gnome-terminal (which is the guilty party) are:
gnome-terminal.x86_64                   3.18.2-1.fc23                   @updates
has the problem fixed it appears now ("who" is OK and "who am i" is also OK).
gnome-terminal.i686                    3.18.2-1.fc23                    @updates
displays no gnome-terminal data (as its not there) at all for "who" just the tty data. "who am i" (as there is no data) displays nothing.

I think the code just needs to be put back in the i686 version too.

NOTE: my x86_64 system updated overnight and now "who am i" appears all OK. Thanks for the fix.
Also I have adjusted the subject so it better reflects the actual error.

Comment 13 Jaroslav Škarvada 2015-11-26 11:31:51 UTC
(In reply to Luigi Cantoni from comment #12)
> Yes "who" is the symptom not the cause. Sorry its just that "who" was how I
> found it.
> The two current versions of gnome-terminal (which is the guilty party) are:
> gnome-terminal.x86_64                   3.18.2-1.fc23                  
> @updates
> has the problem fixed it appears now ("who" is OK and "who am i" is also OK).
> gnome-terminal.i686                    3.18.2-1.fc23                   
> @updates
> displays no gnome-terminal data (as its not there) at all for "who" just the
> tty data. "who am i" (as there is no data) displays nothing.
> 
> I think the code just needs to be put back in the i686 version too.
> 
> NOTE: my x86_64 system updated overnight and now "who am i" appears all OK.
> Thanks for the fix.
> Also I have adjusted the subject so it better reflects the actual error.

Thanks for changing the subject.

The i686 and x86_64 packages are built from the same codebase. AFAIK nothing related was reverted back to the gnome-terminal. I cleanly installed new F23 machine to re-check it and it still doesn't work on x86_64 (cleanly provisioned machine), package:
gnome-terminal-3.18.2-1.fc23.x86_64

Do you use gdm? Which version? Are the gdm versions same on your x86_64/i686? I used vncserver without display manager. I think it should work no matter which DM is used.

Comment 14 Luigi Cantoni 2015-11-26 23:52:42 UTC
I think I was mistaken about x86_64 working. Remote xwindows sessions get logged but not local ones (that machine is a server which I remote to usually).

i686
[lui@luiginb obj]$ who
lui      tty1         Nov 26 07:51 (:0)
[lui@luiginb obj]$ 
dnf installed version
gdm.i686                        1:3.18.2-1.fc23                         @updates

ps results
root      1103     1  0 Nov26 ?        00:00:00 /usr/sbin/gdm
root      1144  1103  0 Nov26 ?        00:00:00 gdm-session-worker [pam/gdm-autologin]
lui       1349  1144  0 Nov26 tty1     00:00:00 /usr/libexec/gdm-x-session --run-script env GNOME_SHELL_SESSION_MODE=classic gnome-session --session gnome-classic
lui       1366  1349  0 Nov26 tty1     00:09:59 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/1001/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3

-----------------------
x86_64
[lui@fcswin obj]$ who
run      tty1         Nov 27 07:27 (:0)
lui      pts/1        Nov 27 07:41 (luiginb.frontlinewindows.com.au)
[lui@fcswin obj]$ 
There should be 2 local user run sessions. Thus in fact it has the same error as the i686.
dnf installed version
gdm.x86_64                       1:3.18.2-1.fc23                        @updates
ps results
root      1819     1  0 07:27 ?        00:00:00 /usr/sbin/gdm
root      1864  1819  0 07:27 ?        00:00:00 gdm-session-worker [pam/gdm-autologin]
run       1908  1864  0 07:27 tty1     00:00:00 /usr/libexec/gdm-x-session --run-script env GNOME_SHELL_SESSION_MODE=classic gnome-session --session gnome-classic
run       1916  1908  0 07:27 tty1     00:00:00 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3

I'm not sure if any of this helps. When the code is put back that will solve it.

Comment 15 Luigi Cantoni 2016-02-01 05:28:13 UTC
It would appear that the 64 bit version has now been restored to the working version as "who" and "who am i" can now locate correct data to display.
On 64 bit machine
dnf list gdm gnome-terminal
gdm.x86_64                       1:3.18.2-1.fc23                        @updates
gnome-terminal.x86_64                   3.18.2-1.fc23                   @updates

On 32 bit machine
dnf list gdm gnome-terminal
gdm.i686                              1:3.18.2-1.fc23                   @updates
gnome-terminal.i686                   3.18.2-1.fc23                     @updates
these appear unchanged so the fix is not in gdm/gnome-terminal.

The 32 bit version is not corrected yet. Will this be done?
Is support for 32 bit version stopping soon?
I note that chrome will no longer be supported for 32 bits.

Comment 16 Luigi Cantoni 2016-06-16 01:19:58 UTC
The 64 bit version has had this problem fixed quite a while ago but the 32 bit version still does not have the code put back again.
Could this please be done in the 32 bit version.
6 months I think is long enough.

dnf list gdm gnome-terminal
gdm.i686                              1:3.18.2-2.fc23                   @updates
gnome-terminal.i686                   3.18.3-2.fc23                     @updates

Comment 17 Luigi Cantoni 2016-07-21 08:28:01 UTC
The fix has now gone from the 64bit version.
I have updated to F24 for my 32 bit version and the problem is not fixed.

F23 (64 bit version is)
dnf list gdm gnome-terminal
gdm.x86_64                             1:3.18.2-2.fc23                  @updates
gnome-terminal.x86_64                  3.18.3-2.fc23                    @updates

F24 (32 bit version)
dnf list gdm gnome-terminal
gdm.i686                           1:3.20.1-3.fc24                 @@commandline
gnome-terminal.i686                3.20.2-2.fc24                   @@commandline

Could this problem be fixed after all this time, especially since it is just put back the code that was removed/disabled.

Comment 18 Zbigniew Jędrzejewski-Szmek 2016-11-18 18:49:23 UTC
Let's close this as WONTFIX. This functionality was always half broken and is clearly not coming back.

Recommendations:

a) Instead of "who am i"
 - use "whoami"
 - or "echo $LOGNAME"

b) "who" and "w" and "loginctl" display useful information about logged in users, but not about individual terminal emulator tabs, so don't rely on the latter.

Comment 19 Luigi Cantoni 2016-11-19 00:58:45 UTC
I am disappointed in this closure.

The reason I am using who is to determine the number of active sessions of me that are running. In the particular case I wish to work out if I am the first active shell as I only want to do something once in the first active shell.
If the decision is to close this off then I will find another way to work out what I want. The problem is not too hard to do even though the suggested comments won't actually help me at all as they all appear to report the faulty (missing) data.

The real reason for my disappointment is:
This makes the 32bit version different to the 64bit version.
The program used to work this way so WHY was it removed.
It should be a very simple matter to put it back.
The 64bit team felt it should be restored as they did that straight away.

Please note who is the symptom not the cause the cause is that gnome-terminal is not writing the records into wtmp file anymore. Just put that code back and all is OK again.

Please restore the code that was was there and return the functionality to how it has been for 20 years.

If you really will not fix it then you really need to get all the other versions 64bit as an example to agree and change theirs. It should not behave differently on different versions.

Comment 20 Zbigniew Jędrzejewski-Szmek 2016-11-19 02:18:19 UTC
You can use ls -l /dev/pts so see how many "sessions" are running.

I don't know why you think the 32bit version is different from the 64 bit version. TTBOMK, they are compiled from the same source code and behave identically. I just tested on 64 bit F25 image, and "who am i" returns nothing in gnome-terminal.

You ask why this was removed. The issue was that this was the implementation requires setuid or setgid helpers to elevate privileges to write to the single shared file. In addition, the mechanism is broken because there's no cleanup when a session crashes, so the data this returns cannot be trusted for anything anyway. The same information can be retrieved from other sources in a more reasonable way.

You changed the status to ASSIGNED. Who do you think is going to work on this?

Comment 21 Luigi Cantoni 2016-11-19 05:24:27 UTC
I will check Monday at work where I have both 64 and 32 bit machines.
If they both behave the same then certainly my biggest concern about different behaviours is not true.
If you can leave it as assigned until Monday when I will check then.
I am sorry if changing it assigned is wrong.
I was unsure if as it is marked as closed means my comments would not get through to you.
If both versions are the same I will close it.

I am probably wrong about them being different because I was remote logging into the 64bit machine and so they were different to using the console which I did on the 32 bit machine.
If they are different maybe someone could explain how/why they are different because if they come from the same source then they should be the same, which they probably are.

I also thank-you for the information about why the functionality was lost. The reason you give is a sound one and I am more then happy to accept that.

Comment 22 Luigi Cantoni 2016-11-21 00:02:26 UTC
I have confirmed that 32 and 64bit act the same.
I will now close this item.
I have also confirmed that crashing Xtermal out causes the wtmp to be updated and thus contains correct data. It far more important that this behaviour be retained like that.

Comment 23 Debarshi Ray 2017-07-03 13:20:50 UTC
*** Bug 1466993 has been marked as a duplicate of this bug. ***


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