You are not logged in.
Hello,
I just installed Arch on a new machine following the installation guide https://wiki.archlinux.org/index.php/Installation_guide. Weirdly, there seems to be some issue with users: In the output of "w", "who" or "last", only the user logged in on a tty (in my case, KDE via SDDM) are shown, but no users logged in on a pts (e.g., via xterm or konsole). Users logged in via ssh on a pts, however, are shown.
The user has been added via
# useradd -m -g users -G wheel -s /bin/bash kifuna
I also tried to add an additional test user via
# useradd -m -g users -s /bin/bash testuser
Logging in with this user to KDE and opening a terminal results in the same behaviour.
Additionally, I also removed my sddm.conf, same result.
I do not know whether this is related, but my ~/.profile does not get sourced, neither when opening konsole or xterm in KDE nor when logging in on a tty.
I am running some other Arch installations, there everything behaves normally.
What is going on? I would be grateful for any clue!
Last edited by kifuna (2018-04-22 21:17:17)
Offline
loginctl show-session $XDG_SESSION_ID
bash tries ~/.bash_profile, ~/.bash_login, and ~/.profile in that order and stops as soon as it finds one of them.
Offline
Thank you, seth!
I removed ~/.bash_profile and after a reboot ~/.profile is indeed sourced.
Still, "w", "who" and "last" do not show pts users. Here is the output from your query:
loginctl show-session $XDG_SESSION_ID
Id=c2
User=1000
Name=kifuna
Timestamp=Sat 2018-04-21 14:52:53 CEST
TimestampMonotonic=7444981
VTNr=7
Seat=seat0
Display=:0
Remote=no
Service=sddm
Desktop=KDE
Scope=session-c2.scope
Leader=511
Audit=0
Type=x11
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
LockedHint=no
Output when logging in via ssh:
loginctl show-session $XDG_SESSION_ID
Id=c3
User=1000
Name=kifuna
Timestamp=Sat 2018-04-21 14:55:25 CEST
TimestampMonotonic=159882638
VTNr=0
Remote=yes
RemoteHost=[REMOVED BY ME]
Service=sshd
Scope=session-c3.scope
Leader=994
Audit=0
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
LockedHint=no
Is there anything suspicious?
Offline
Is there anything suspicious?
Nope. I had "hoped" for an inactive user or no session at all (hinting the sublying problem)
Permission issue?
strace who
Offline
Here is the output of
strace who
Edit: I just tried LXDM instead of SDDM, then "who", "w" and "last" report that no one is logged in.
Last edited by kifuna (2018-04-21 16:11:12)
Offline
Can you post the strace for who from a user logged in that does in the who output for comparison please.
How exactly are the users logged in on pts?
Offline
Here is the output of
strace who
when logging in via ssh. Then the user shows up in the output (pts/9):
I log in by starting KDE via SDDM and then opening konsole or xterm. When I do the same on my other Arch machines, these interactive sessions are correctly shown by "who" etc.
Offline
Both show a login on tty7 and the second one a login on pts/9
write(1, "kifuna tty7 2018-04-21"..., 44kifuna tty7 2018-04-21 17:53 (:0)) = 44
write(1, "kifuna tty7 2018-04-21"..., 98kifuna tty7 2018-04-21 18:25 (:0)
kifuna pts/9 2018-04-21 18:32 ([IP REMOVED BY ME])) = 98
According to post #3, VTNr=7 is your sddm driven login? (and it does have DISPLAY :0 in the strace)
iow: the strace output does not suggest a "problem"??
Offline
Exactly, tty7 is the graphical login to KDE via SDDM. All the other open konsole windows, i.e., all the other pts (except those related to an ssh login), are invisible as if no one were logged in. This is all very obscure. On all my other computers w gives the following output:
USER TTY LOGIN@ IDLE JCPU PCPU WHAT
kifuna tty7 19:52 2:24m 31.92s 0.01s /bin/sh /usr/bin/startkde
kifuna pts/0 19:52 3.00s 0.04s 0.00s w
kifuna pts/1 19:52 2:23m 0.00s 2.20s kded5 [kdeinit5]
Last edited by kifuna (2018-04-21 20:24:50)
Offline
I don't see a "problem". Read https://unix.stackexchange.com/question … ogin-shell
Offline
This would be the VTE editing utmp, see https://unix.stackexchange.com/question … utmp-entry
Maybe konsole has a config switch for this?
(Please notice that what you concern in the common case, the additional entries per VTE are the oddity)
Edit: apparently xterm does this by default.
Last edited by seth (2018-04-21 21:01:19)
Offline
Wait, do I understand correctly that w, who and last are basically useless because it is the expected behavior that they should not report local logins via VTEs? Then I really do not understand what's different in my other Arch Linux installations. Something must have changed at some point that does not affect old installations but new ones. What could this be?
Edit: apparently xterm does this by default.
Sorry, what is xterm doing by default?
@jasonwryan: Thank you, this nicely explains the (in the end unrelated) issue regarding ~/.profile.
Last edited by kifuna (2018-04-21 23:03:52)
Offline
seth wrote:Edit: apparently xterm does this by default.
Sorry, what is xterm doing by default?
using utempter to update utmp for every terminal it managers.
@jasonwryan: Thank you, this nicely explains the (in the end unrelated) issue regarding ~/.profile.
The connection is opening a terminal is creating a none login interactive shell the key being none login.
With the ssh and console sessions there has been a login.
Edit:
What is the output on the old and new systems of
getent group utmp
Last edited by loqs (2018-04-22 00:07:23)
Offline
That's weird, as I mentioned in my first post xterm also does not show up in who although libutempter is installed?
I understand your explanation regarding login/non-login shells. What I still want to find out is why my two installations behave differently with respect to utmp.
Here is the output of
getent group utmp
on the new installation:
utmp:x:996:
and on my older installation:
utmp:x:20:
Offline
Could be https://git.archlinux.org/svntogit/pack … empter#n24 libutempter needs utmp to have a gid of 20
Offline
Wow, loqs, thanks a lot, that was the issue! I now changed the gid of the utmp group to 20 and after a reboot konsole and xterm pts sessions are again report by who.
Before marking this thread as solved: Is it to be considered a bug that Arch Linux now creates the utmp group with gid 996 - thus breaking libutempter compatibility - or is this on purpose to prepare for future changes? According to https://wiki.archlinux.org/index.php/De … D_Database "filesystem" should create the utmp group with gid 20. What I understand from https://bbs.archlinux.org/viewtopic.php?id=234525 it is systemd-sysusers that creates the group utmp with gid 996. The switch to systemd-sysusers seems to have happened very recently: https://www.archlinux.org/todo/switch-t … -sysusers/
Last edited by kifuna (2018-04-22 13:29:00)
Offline
https://bugs.archlinux.org/task/57041#comment165374
This was the change that removed utmp from being present in /etc/groups as provided by filesystem that prevented /usr/lib/sysusers.d/basic.conf as provided by systemd from creating the group with a dynamic gid.
Looking at package releases I have cached I believe filesystem-2017.10-2 was the first none testing release with the issue.
On new systems the issues should have been occurring since that release of filesystem or 5+ months ago without anyone reporting it.
Offline
Thanks for these explanations, loqs! The related commit to filesystem seems to be "Winter has come.": https://git.archlinux.org/svntogit/pack … a0b1706ae8
I have filed a bug report for libutempter: https://bugs.archlinux.org/task/58306
Offline