/usr/bin/who returns no user...

Bug #861388 reported by Richard Sellam
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xfce4-terminal (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Tested with latest daily xubuntu.

Expected: get the list of logged on users with /usr/bin/who
What happened: empty list...

Since this is a core feature, i consider it critical for release.

Affects : Ubuntu 11.10 oneiric (Xubuntu)
coreutils 8.5-1ubuntu6

Revision history for this message
Richard Sellam (richard-sellam) wrote :

I did several tests, and it looks like it's working correctly on tty (ctrl+alt+f1-6), unity and openbox.
Bug is still here when selecting xubuntu or gnome-shell in lightdm... It's probably related to the desktop environment, but i'm not really sure how and where to fix this.

Revision history for this message
C de-Avillez (hggdh2) wrote :

Thank you for opening this bug and helping make Ubuntu better.

Indeed, 'who' uses data stored on a system file (utmp, for Linux); this file is populated by other binaries, and its correctness depends on the binaries. From 'man 5 utmp':

"The utmp file allows one to discover information about who is currently using the system. There may be more users currently using the system, because not all programs use utmp logging."

If a login record is not written, then 'who' cannot report on it.

This is not a bug for 'who'; it could be considered, perhaps, a bug on a session manager -- I do not know --. You can also look at bug 268780; comment #3 is more to the point of your bug.

I am unsure on how to proceed here, so I will leave it New. You might want to add an "Affects" for your session manager.

Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here.

I am able to confirm this issue using Oneiric Ocelot. When running /usr/bin/who in a terminal in the live session, I see

ubuntu tty3 2011-10-12 22:11
ubuntu tty2 2011-10-12 22:11
ubuntu tty5 2011-10-12 22:11
ubuntu tty6 2011-10-12 22:11
ubuntu tty4 2011-10-12 22:11
ubuntu tty1 2011-10-12 22:11

When I run the same command on a fresh installation of Xubuntu, I see no response. If I run it in TTY1, I get

$USER tty1 2011-10-12 16:15

Running the same command in terminal in Xubuntu 10.04, I get the expected user as a response.

Thanks for taking the time to make Ubuntu better!

Changed in coreutils (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Richard Sellam (richard-sellam) wrote :

problem is not related to /usr/bin/who, but lies in xfce4-terminal

affects: coreutils (Ubuntu) → xfce4-terminal (Ubuntu)
Revision history for this message
Richard Sellam (richard-sellam) wrote :

The real problem is how xfce opens the session and any terminal. It might be because it's not stated as a login.
From an Xubuntu system, logging in and launching who results in an empty list.
Switch to a tty (ctrl+alt+f1-6) and log in there, and you'll see the tty session user if you run who again on the xubuntu session.
Also, using xterm instead of xfce4-terminal results in a correct behavior, so it looks like only xfce session and xfce4-terminal are affected by this bug (gnome-shell is also affected by the exact same bug).

I hope it helps.

Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

The vte helper isn't at the correct location, cf. https://bugs.launchpad.net/ubuntu/+source/vte/+bug/864609

Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

Why is gnome-shell, which does not use Xfce or xfce4-terminal affected if this is caused by Xfce?

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Revision history for this message
C de-Avillez (hggdh2) wrote :

Lionel pointed to the real cause of this -- bug 864609 -- for Xfce. I think this bug could be set as a dup. Thank you, dear sir. BUT note that this will only create entries if -- after fixed -- xfce-terminal is used.

@Charlie: the problem here is not actually Xfce, or Gnome, or any other SM. Sort of. The utmp protocol is unreliable -- it was originally written for the command line UNIX, and it was never -- to my knowledge -- ported to X. For the data to be reliable, all programs would have to use it (or all session managers, under a graphical environment). Most do not...

I am not sure there is an equivalent under the graphical environment. So... if you go to a pseudo-terminal and log in, 'who' will report it -- because /bin/login calls the utmp protocol to update the entries. Most terminal emulators -- gnome-terminal, roxterm, xterm, xfce-terminal -- either populate utmp, or have an option to do so. But, chances are you will have no entries there if you just logged in on your graphical environment.

The email I linked (from the Coreutils ML, upstream) in bug 268780 has a very succint explanation:

"The utmp file is a very old part of unix-like systems. I doubt if
today, 30 years later, that it would be implemented the same way that
it was originally implemented bay back then. Note that the utmp and
wtmp files are running totals kept by various system programs. Some
programs put things in. Other programs take things out. If any
problems arise then the state is out of sync. Some information is
similar and duplicated from the system's "syslog" file. There is very
little good use of the utmp file today. This is as true on GNU/Linux
as it is on HP-UX, Solaris, AIX, etc."

I do think it might be interesting to come up with an equivalent for the graphical environment; this would have to be agnostic (and, probably, under freedesktop.org, Linux Standard Base, or whatever) so it could be used by all graphical environments. I very much expect a lot of discussions on even deciding on what would be logged, if it is accepted at all.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.