Bug 18032 - sddm fails to register logins in /run/utmp
Summary: sddm fails to register logins in /run/utmp
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High critical
Target Milestone: Mageia 7
Assignee: KDE maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 6sta1, 6sta2
: 20638 (view as bug list)
Depends on:
Blocks: 18057
  Show dependency treegraph
 
Reported: 2016-03-18 16:10 CET by Barry Jackson
Modified: 2017-07-05 16:01 CEST (History)
8 users (show)

See Also:
Source RPM: sddm
CVE:
Status comment:


Attachments

Description Barry Jackson 2016-03-18 16:10:09 CET
Description of problem:
'users' returns nothing in Plasma. so scripts that rely on this to get the current logged on user fail.


[baz@jackodesktop ~]$ urpmf $(which users)
coreutils:/usr/bin/users
coreutils:/usr/bin/users

[baz@jackodesktop ~]$ /usr/bin/users

[baz@jackodesktop ~]$ rpm -q coreutils
coreutils-8.25-2.mga6

[baz@jackodesktop ~]$ urpmq -f coreutils                                                                                                  
coreutils-8.25-2.mga6.x86_64


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
Comment 1 Barry Jackson 2016-03-18 16:35:57 CET
Same for:
[baz@jackodesktop ~]$ /usr/bin/who

[baz@jackodesktop ~]$ /usr/bin/w
 15:33:43 up  3:29,  0 users,  load average: 0.15, 0.15, 0.15
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
Comment 2 David Walser 2016-03-18 19:43:34 CET
I'm guessing the 'last' command isn't showing you either.

SDDM needs to be doing something like the sessreg commands in /etc/X11/xdm/Xstartup (on login) and /etc/X11/xdm/Xreset (on logout).  I think KDM has something equivalent hard-coded into it.

CC: (none) => doktor5000
Assignee: bugsquad => mageia

Comment 3 Barry Jackson 2016-03-19 17:12:01 CET
[baz@jackodesktop ~]$ last
reboot   system boot  4.4.6-desktop-1. Sat Mar 19 16:08   still running

wtmp begins Sat Mar 19 11:45:06 2016
[baz@jackodesktop ~]$
Barry Jackson 2016-03-19 17:25:45 CET

CC: (none) => neoclust

Barry Jackson 2016-03-19 17:26:20 CET

CC: neoclust => (none)

Barry Jackson 2016-03-23 12:56:37 CET

Blocks: (none) => 18057

Comment 4 Nicolas Lécureuil 2016-06-04 00:17:11 CEST
can you test on other DE ?
Comment 5 Barry Jackson 2016-06-04 01:25:21 CEST
Not that simple it seems.
Just logging out and back in on another DE is not enough, as something changes at system level and once it's working it then can work in other DEs until a re-boot.

I just went through:
Plasma Not working
LXDE LXTerminal Not working, MATE-terminal working after which LXTerminal is OK!
After which all these were OK:
LXQT 
MATE
OPENBOX
XFCE
IceWM
...and then so was plasma in konsole.

After re-boot plasma failed in konsole and it's now working again maybe after testing in tty2 - it's late and I'm beginning to lose concentration.

Not sure if any of that helps or makes it worse :\
Comment 6 Barry Jackson 2016-06-04 13:13:22 CEST
OK after some sleep I re-tested each DE from a reboot and login via sddm

'users' returns my username in these:

MATE
XFCE

'users' returns nothing in these:

Plasma
IceWM
LXQT
LXDE
Openbox
Comment 7 Barry Jackson 2016-06-04 13:30:15 CEST
A couple more tests:

Logging into a tty as user (without previously logging in anywhere) returns username correctly.

Logging into Plasma with a new user still returns nothing.
Comment 8 Barry Jackson 2016-06-23 18:01:36 CEST
I upped the severity/priority as I feel this is slipping under the radar - feel free to drop it again.

Keywords: (none) => 6sta1
Severity: major => critical
Priority: Normal => High

Comment 9 Stephen Pettin 2016-06-26 16:23:43 CEST
I'm getting the same issue with 'who' command. 

User saptech (tty2) is displaying nothing for 'who' command but my user1 (tty1) does show only user1 info with the 'who' command. After a while, user saptech is now showing user1 info only.

Saptech is user2(tty2) running Plasma5. debbie is user1(tty1) and running Mate Mga6
[saptech@localhost ~]$ w
 09:06:43 up 43 min,  1 user,  load average: 0.72, 0.89, 0.78
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
debbie   pts/1     08:40   25:46   0.02s  0.02s bash
[saptech@localhost ~]$ who
debbie   pts/1        2016-06-26 08:40 (:0)
[saptech@localhost ~]$ users
debbie
[saptech@localhost ~]$ last
debbie   pts/1        :0               Sun Jun 26 08:40   still logged in
reboot   system boot  4.6.3-desktop-1. Sun Jun 26 03:23   still running
debbie   pts/1        :1               Sun Jun 26 08:14 - 08:22  (00:08)

CC: (none) => saptech

Barry Jackson 2016-06-26 16:32:37 CEST

Summary: 'users' returns nothing in Plasma (maybe other DEs as well) => 'users' returns nothing in Plasma, IceWM, LXQt, LXDE and Openbox

Comment 10 David Walser 2016-07-06 21:00:15 CEST
The DE or WM you're logging into isn't relevant here, it's the method you're using to log in, in this case SDDM, which isn't doing something it should be.

Summary: 'users' returns nothing in Plasma, IceWM, LXQt, LXDE and Openbox => sddm fails to register logins in /run/utmp

Comment 11 Chris Denice 2016-07-14 15:03:51 CEST
Confirmed here too. That's quite a security issue indeed...
Unrelated, but if one checks the bug list we have on sddm, that's scary to use that as a default dm :-/

CC: (none) => eatdirt

Comment 12 David Walser 2016-08-10 00:32:01 CEST
Still the case.

Source RPM: coreutils-8.25-2.mga6.x86_64 => sddm
Blocks: 18057 => 15527

David Walser 2016-08-10 14:07:18 CEST

Blocks: (none) => 18057

Comment 13 David Walser 2016-08-16 17:46:49 CEST
Has anyone tried this with SDDM on any other distro?

It appears to me to be an upstream bug.  There isn't any configurable way to hook in xdm's Xstartup/Xreset scripts (run at login/logout as root), so it needs to be hardcoded into it the same way it must be in KDM, and it's just not doing it.

CC: (none) => luigiwalser

Comment 14 Neal Gompa 2016-08-16 23:01:00 CEST
On Fedora 24 (Plasma 5 + SDDM):

[neal ~]$ w
 16:59:42 up 9 days, 23:29, 10 users,  load average: 0.79, 1.31, 1.36
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
neal     pts/2     06Aug16  9days  0.00s  1:20  kded5 [kdeinit5]                                      
neal     pts/3     06Aug16  4days  0.02s  0.00s /usr/bin/fish
neal     pts/4     06Aug16  4days  0.17s  0.00s /usr/bin/fish
neal     pts/5     08Aug16  7days  0.07s  0.01s /usr/bin/fish
neal     pts/6     09Aug16  7days  0.48s  0.45s /usr/bin/fish
neal     pts/7     09Aug16  3days  1.12s  0.71s /usr/bin/fish
neal     pts/8     Mon18   30.00s  0.46s  0.46s /usr/bin/fish
neal     pts/9     Fri15    3days  1.42s  0.33s /usr/bin/fish
neal     pts/10    16:59    4.00s  0.03s  0.00s w
neal     pts/11    Mon11   28:54m  0.35s  0.28s /usr/bin/fish

CC: (none) => ngompa13

Comment 15 David Walser 2016-08-16 23:13:09 CEST
On Mageia 5 I have:
 17:11:52 up 20 days,  3:44,  2 users,  load average: 0.00, 0.06, 0.07
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
david    :0        27Jul16 ?xdm?  30:56m  0.02s /bin/sh /usr/bin/startkde
david    pts/0     27Jul16 20days  0.00s 36.66s kdeinit4: kded4 [kdeinit]

I'm not sure why I don't see a kded5 one in Cauldron, but the one we're really missing is the :0 one, which doesn't show in Neal's output either.  Looks like an upstream SDDM bug indeed.
Samuel Verschelde 2016-08-25 16:23:03 CEST

Assignee: mageia => kde

Samuel Verschelde 2016-09-22 11:04:35 CEST

Target Milestone: --- => Mageia 6

Comment 16 Chris Denice 2016-11-24 16:22:11 CET
I have played around these days with this issue.

This is definitely a SDDM bug, and more generically, this is a bug of others supposedly cool display managers. They simply omit to register logged users as well:

To summarize, right now:
sddm, lxdm don't register logged users.
xdm, gdm, lightdm does.

NB: xdm does it by using sessreg:


cat /etc/X11/xdm/Xstartup | grep sessreg
# sessreg uses the parent pid, so we have to exec it
exec /usr/bin/sessreg -a -w "/var/log/wtmp" -u "/var/run/utmp" \

So, I guess it should be possible to add such commands somewhere for the others DM. lxdm provides scripts in /etc/lxdm/ but sddm does not.

My humble opinion would be to fix this bug by not following the KDE recommendation of using sddm...
Comment 17 David Walser 2016-11-24 16:45:35 CET
Chris, I had the same thought a few days ago and meant to say something, that perhaps we should use lightdm.  sddm doesn't current provide a hook to run a script as root when someone logs in, which would be needed to call the same script that xdm does to call sessreg.
Comment 18 Neal Gompa 2016-12-03 22:23:59 CET
This seems to be fixed in SDDM included in Fedora 25:

[neal@ ~]$ rpm -q sddm
sddm-0.14.0-6.fc25.x86_64


[neal ~]$ w
 16:22:10 up 2 days, 56 min, 11 users,  load average: 1.82, 1.21, 1.46
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
neal     pts/0     Thu15    2days  0.00s 23.29s kded5 [kdeinit5]                                      
neal     pts/1     Thu16    2days  0.02s  0.00s /usr/bin/fish
neal     pts/5     Thu16    2days  0.31s  0.00s /usr/bin/fish
neal     pts/6     Thu16    2days  0.01s  0.00s tmux
neal     pts/7     Thu16    2days  1.92s  1.83s /usr/bin/fish
neal     pts/8     Thu16    2days  0.33s  0.04s vim control
neal     pts/9     Thu16   29:19m 39:32   0.01s bash
neal     pts/10    Fri12    3:49m 14.15s 10.09s /usr/bin/fish
neal     pts/11    14:00    1:47m  0.58s  0.58s /usr/bin/fish
neal     pts/13    14:20    1:10m  0.07s  0.01s /usr/bin/fish
neal     pts/14    14:53    1.00s  1.03s  0.01s w
Comment 19 Nicolas Lécureuil 2016-12-03 22:38:29 CET
works in mga using sddm service.

can it be a prefdm bug too ?

CC: (none) => mageia

Comment 20 Neal Gompa 2016-12-03 22:39:33 CET
(In reply to Nicolas Lécureuil from comment #19)
> works in mga using sddm service.
> 
> can it be a prefdm bug too ?

I think it is. It appears to work fine when I switch to the sddm service, too.
Samuel Verschelde 2017-01-17 10:29:39 CET

Blocks: 15527 => (none)

Comment 21 Chris Denice 2017-02-03 14:32:11 CET
Does not work for me using sddm.service. I am logging in with fvwm2 and symptoms are exactly the same than with prefdm:

14:31:26 up 7 min,  0 users,  load average: 0.25, 0.29, 0.15
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
Nicolas Lécureuil 2017-03-12 09:16:28 CET

Target Milestone: Mageia 6 => Mageia 7

Marja Van Waes 2017-04-09 15:32:11 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=20638

Comment 22 aguador 2017-04-10 22:18:07 CEST
As 20638 is currently inaccessible and does seem to be duplicate of this, so I will comment here. LXDM fails in Terminology, LXTerminal, XTerm and urxvt under E21. I would have tried Mate Terminal, but it simply crashed.

Yesterday I checked and found that lxdm.service was not enabled in systemd. However, enabling it seemed to have no effect. (As an aside, how is it that lxdm works without having the service enabled in systemd?)

CC: (none) => aguador

Comment 23 Marja Van Waes 2017-04-18 11:40:12 CEST
*** Bug 20638 has been marked as a duplicate of this bug. ***

CC: (none) => smelror

Comment 24 Stig-Ørjan Smelror 2017-05-20 20:38:28 CEST
Hi.

When I use su, the root user isn't shown.

But when I use "machinectl shell", the root user shows up.

Installed using the network iso of sta2 and updated as of this hour.

It's been an issue for over a year. Is there a solution on the horizon?

Thanks in advance.

Keywords: (none) => 6sta2

Comment 25 Chris Denice 2017-07-05 16:01:24 CEST
No. I looked hard to find a hook in the sddm starting scripts to manually add user counting, but all the hooks are either too late of too early in the process of starting a session. Then, upstream do not care, so unfortunately, the only current solution is to move away from sddm. In my office we have switched to lightdm, it is ugly but works fine. With a bit more time for mga6, we could have designed a nice theme for lightdm and use it as the default DM, maybe we could do this for mga7 if upstream goes on focusing only on appearance instead of descent coding.

I have added a comment in the errata on this issue.

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