Description of problem: I created two users and try to login with both of them and then to switch between them. Firstly I login as first user. Then I go to Menu->Leave->Switch User - then I create new session and login and second user. Then I'd like to login back as first user, but after I click on Switch user and then again on Switch the desktop freezes. System itself works further but you can't switch to another virtual terminal. But if you are sshd to the machine you can work with it. But if you have no other pc you have to restart machine, which means to lose both sessions. I also tried to logoff from first user and login to the second and then logoff and login as first user again. This work flow works fine (but sessions are terminated). In one case (just one so far) it happened to me that after some time (about 10 minutes) the active session (the one where it froze) got locked. I could unlock as usually and then the switching worked fine (I could switch between both users without problems). But I wasn't able to reproduce this behaviour. Version-Release number of selected component (if applicable): sddm-0.13.0-7.fc25.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: I propose this as a Final blocker. Because Switching user button can be found on menu this violates the final criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. "
Discussed during the 2016-10-17 blocker review meeting: [1] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria: Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops" as 'switch user' is an offered mechanism, with 1184933 as precedent. Please note, we don't require this functionality to be in Fedora so if the decision is made to remove or disable this from Fedora, we will accept that as an appropriate fix. Also, if the fix cannot be made in time for release, please let us know so we can decide what to do from there. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-10-17/f25-blocker-review.2016-10-17-16.02.txt
Does anybody else exhibit this issue? I wasn't able to reproduce this bug when I tried it in F25 Beta Live image. I added one user, created a new session from the session picker for him and I can switch freely from one to another without a problem.
I tried with a fully updated F25 KDE in a VM (spice, qxl). It seems we received some KDE updates and it now behaves a bit differently. The versions I have: sddm-0.14.0-1.fc25.x86_64 plasma-desktop-5.8.1-1.fc25.x86_64 User switching works fine for me. However, it seems that *logging out* is broken after you use user switching. I see two different scenarios. I'll attach logs and reproducer descriptions.
Created attachment 1212417 [details] all sessions killed - journal All sessions are killed if user2 logs out. Reproducer: 1. boot the system 2. log in with user1 3. switch to user2 4. log out user2 5. see that user1 has been logged out (or killed) as well. TTY2 is now empty (should not be). If you try to log in as user1, you get a new session (you should get back to the existing session). Sometimes I see an error flash about "kmserver could not be started" or something like that right before login screen is shown.
Created attachment 1212418 [details] black screen instead of login screen - journal Only black screen instead of login screen is shown, if user1 logs out. Reproducer: 1. boot the system 2. log in with user1 3. switch to user2 4. switch to user1 5. log out user1 6. see only black screen, no login screen. However, you can manually switch to TTY2 to see that user2 session is still running. So this is just the login screen being hung.
Created attachment 1212419 [details] rpm -qa output
A bit more detail on comment #4, "All sessions are killed if user2 logs out", from a F24 VM install. It might be related to the qxl driver. There's some more info in the Xorg.*.log.* files, which contain some error lines not present in the journal (for some reason). After seeing that user1's session has been killed, I logged in via ssh: $ loginctl SESSION UID USER SEAT c3 993 sddm seat0 7 1000 test 5 1001 second seat0 2 1000 test seat0 4 sessions listed. $ loginctl show-session c3 Id=c3 User=993 Name=sddm Timestamp=Tue 2016-11-01 16:09:31 GMT TimestampMonotonic=504360655 VTNr=1 Seat=seat0 Display=:0 Remote=no Service=sddm-greeter Scope=session-c3.scope Leader=2916 Audit=0 Type=x11 Class=greeter Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 $ loginctl SESSION UID USER SEAT c3 993 sddm seat0 7 1000 test 2 1000 test seat0 3 sessions listed Looks like session 5 isn't cleaned up until loginctl tickles something. If I repeat "loginctl" then session 5 it still listed, only show-session seems to get it cleared up. $ loginctl show-session 2 Id=2 User=1000 Name=test Timestamp=Tue 2016-11-01 16:03:03 GMT TimestampMonotonic=115473047 VTNr=1 Seat=seat0 Display=:0 Remote=no Service=sddm Desktop=KDE Scope=session-2.scope Leader=952 Audit=2 Type=x11 Class=user Active=no State=closing IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 This is the user1 session that 'crashed' but it persists in the 'closing' state until something else logs in on vt1. And here's the output of 'ps aux | grep test' (logged in at the terminal as root so that the ssh sessiion doesn't pollute it) - showing what remains of the session. test 964 0.0 0.2 47596 5052 ? Ss 16:03 0:00 /usr/lib/systemd/systemd --user test 966 0.0 0.1 179676 3412 ? S 16:03 0:00 (sd-pam) test 979 0.0 0.1 117664 2868 ? S 16:03 0:00 /bin/sh /usr/bin/startkde test 997 0.1 0.2 59204 4892 ? Ssl 16:03 0:01 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only test 1002 0.0 0.0 51316 580 ? Ss 16:03 0:00 /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "/usr/bin/startkde" test 1075 0.0 0.6 328948 12428 ? Sl 16:03 0:00 /usr/libexec/mission-control-5 test 1277 0.0 0.2 261832 5308 ? Ssl 16:03 0:00 /usr/libexec/at-spi-bus-launcher test 1281 0.0 0.2 58472 4156 ? Sl 16:03 0:00 /bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 test 2898 0.0 0.2 146572 4884 ? S 16:09 0:00 xmessage -geometry 500x100 Could not start ksmserver. Check your installation. test 2907 0.0 1.6 651744 33220 ? Sl 16:09 0:00 /usr/bin/kglobalaccel5 root 3267 0.0 0.0 117140 976 tty2 S+ 16:19 0:00 grep --color=auto test Xorg logs to follow.
Created attachment 1216197 [details] Xorg.0.log.old of 'crashed' user1 session Note the warning (WW) and error (EE) lines.
Created attachment 1216198 [details] Xorg.1.log of logged out user2 session. Note the "(EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied" etc. lines not present in Xorg.0.log.old
Adding "-keeptty" to ServerArguments (and uncommenting it) in /etc/sddm.conf appears to solve the "All sessions are killed if user2 logs out" problem, at least so far. (It doesn't seem to make any difference to comment #5 - "Only black screen instead of login screen is shown, if user1 logs out") I also forgot to mention that I can't reproduce the problem with gdb attached (from a remote ssh session and with "handle" nostop for SIGIPE and SIGUSR1 - following https://www.x.org/wiki/Development/Documentation/ServerDebugging/) but could reliably reproduce it without gdb.
There is the same report upstream here: https://github.com/sddm/sddm/issues/653
(In reply to Martin Bříza from comment #11) > There is the same report upstream here: > https://github.com/sddm/sddm/issues/653 Note that the upstream report describes comment #5, not comment #4 or comment #0.
(In reply to Oliver Henshaw from comment #10) > Adding "-keeptty" to ServerArguments (and uncommenting it) in /etc/sddm.conf > appears to solve the "All sessions are killed if user2 logs out" problem, at > least so far. > Appears I spoke too soon. It doesn't make a difference today.
I guess the problem described in Comment #5 Should be a separate bug. I attempted to fix that in this PR: https://github.com/sddm/sddm/pull/735
A scratch build for testing: http://koji.fedoraproject.org/koji/taskinfo?taskID=16279725
(In reply to Martin Bříza from comment #15) > A scratch build for testing: > http://koji.fedoraproject.org/koji/taskinfo?taskID=16279725 This fixes the problem mentioned in comment 5. It does not fix comment 4.
The problem described in comment 4 doesn't happen on my box unfortunately. Could probably be related to the fact you're in a VM. It's a bit late today but we're gonna test this tomorrow if we can find a solution. From a glance at your journal it seems a bit odd the first user's session wasn't actually ended, as Oliver mentioned.
I used perf to trace what processes use the DRM_SET_MASTER and DRM_DROP_MASTER syscalls. It looks like the Xorg on vt1 tries to get control of the DRM master before the Xorg on vt2 releases it - in fact there's no DRM_DROP_MASTER from the vt2 Xorg during logout so I think it only gets released when the fd is closed. I tried to add a filter for the close(2) event for the drm master fd in each process, but didn't get anything. Grepping the xf86-video-qxl code it doesn't look like drmClose is used in anything but an error path, so the fd is only closed when Xorg exits unless I'm missing something. (It's a little more tricky to get the sys_exit_ioctl event corresponding to the DRM_SET_MASTER etc. calls so couldn't confirm the return values, but it does correlate to the error message in the Xorg.0.log.old) Trying to do this with strace instead of perf makes the bug disappear - seems it's timing dependent. 1. Login as user1, create a new session for user2 2. Switch to a text terminal # pgrep -fla Xorg ... [shows xorg on vt1 is pid 4844, xorg on vt is pid 5885] ... 4. switch to a text terminal # perf record -e syscalls:sys_enter_ioctl --filter 'cmd == 0x641e || cmd == 0x641f' -e sched:sched_process_exit --filter 'pid == 4844 || pid == 5885' -e sched:sched_process_free --filter 'pid == 4844 || pid == 5885' --call-graph dwarf -a -D 5000 -T -o perf_logouttwo_more.data sleep 120 5. logout from user2, wait two minutes and switch back to the text terminal # perf script -i perf_logouttwo_more.data Xorg 4844 [000] 3373.156721: syscalls:sys_enter_ioctl: fd: 0x00000015, cmd: 0x0000641e, arg: 0x00000000 f8b67 __GI___ioctl+0xffff005ba85ce007 (/usr/lib64/libc-2.23.so) 42b8 drmIoctl+0xffff005ba5e14028 (/usr/lib64/libdrm.so.2.4.0) 12888 qxl_enter_vt_kms+0xffff005bb2a2a028 (/usr/lib64/xorg/modules/drivers/qxl_drv.so) b6d7d xf86RandR12EnterVT+0xffffffffff80007d (/usr/libexec/Xorg) 79940 xf86VTEnter+0xffffffffff800070 (/usr/libexec/Xorg) 3b94d WakeupHandler+0xffffffffff80006d (/usr/libexec/Xorg) 197fb9 WaitForSomething+0xffffffffff8001e9 (/usr/libexec/Xorg) 36bde Dispatch+0xffffffffff80008e (/usr/libexec/Xorg) 3add3 dix_main+0xffffffffff8003d3 (/usr/libexec/Xorg) 20731 __libc_start_main+0xffff005ba85ce0f1 (/usr/lib64/libc-2.23.so) 24d59 _start+0xffffffffff800029 (/usr/libexec/Xorg) Xorg 4844 [000] 3373.157012: syscalls:sys_enter_ioctl: fd: 0x00000015, cmd: 0x0000641f, arg: 0x00000000 f8b67 __GI___ioctl+0xffff005ba85ce007 (/usr/lib64/libc-2.23.so) 42b8 drmIoctl+0xffff005ba5e14028 (/usr/lib64/libdrm.so.2.4.0) 12902 qxl_leave_vt_kms+0xffff005bb2a2a032 (/usr/lib64/xorg/modules/drivers/qxl_drv.so) 7b91f AbortDDX+0xffffffffff80007f (/usr/libexec/Xorg) 1a79f2 AbortServer+0xffffffffff800022 (/usr/libexec/Xorg) 1a87fd [unknown] (/usr/libexec/Xorg) 79ad6 [unknown] (/usr/libexec/Xorg) 3b94d WakeupHandler+0xffffffffff80006d (/usr/libexec/Xorg) 197fb9 WaitForSomething+0xffffffffff8001e9 (/usr/libexec/Xorg) 36bde Dispatch+0xffffffffff80008e (/usr/libexec/Xorg) 3add3 dix_main+0xffffffffff8003d3 (/usr/libexec/Xorg) 20731 __libc_start_main+0xffff005ba85ce0f1 (/usr/lib64/libc-2.23.so) 24d59 _start+0xffffffffff800029 (/usr/libexec/Xorg) Xorg 5885 [000] 3373.195317: sched:sched_process_exit: comm=Xorg pid=5885 prio=120 7fffa60a7b20 do_exit+0x80005a003560 ([kernel.kallsyms]) 7fffa60a8197 do_group_exit+0x80005a003047 ([kernel.kallsyms]) 7fffa60a8214 sys_exit_group+0x80005a003014 ([kernel.kallsyms]) 7fffa6006d52 do_syscall_64+0x80005a003062 ([kernel.kallsyms]) 7fffa67ef661 return_from_SYSCALL_64+0x80005a003000 ([kernel.kallsyms]) rcuos/0 9 [000] 3373.199799: sched:sched_process_free: comm=Xorg pid=5885 prio=120 7fffa60a6039 delayed_put_task_struct+0x80005a003069 ([kernel.kallsyms]) 7fffa610b0fd rcu_nocb_kthread+0x80005a0032ad ([kernel.kallsyms]) 7fffa60c3638 kthread+0x80005a0030d8 ([kernel.kallsyms]) 7fffa67ef7bf ret_from_fork+0x80005a00301f ([kernel.kallsyms]) Xorg 4844 [000] 3373.243504: sched:sched_process_exit: comm=Xorg pid=4844 prio=120 7fffa60a7b20 do_exit+0x80005a003560 ([kernel.kallsyms]) 7fffa60a8197 do_group_exit+0x80005a003047 ([kernel.kallsyms]) 7fffa60a8214 sys_exit_group+0x80005a003014 ([kernel.kallsyms]) 7fffa6006d52 do_syscall_64+0x80005a003062 ([kernel.kallsyms]) 7fffa67ef661 return_from_SYSCALL_64+0x80005a003000 ([kernel.kallsyms]) rcuos/0 9 [000] 3373.257202: sched:sched_process_free: comm=Xorg pid=4844 prio=120 7fffa60a6039 delayed_put_task_struct+0x80005a003069 ([kernel.kallsyms]) 7fffa610b0fd rcu_nocb_kthread+0x80005a0032ad ([kernel.kallsyms]) 7fffa60c3638 kthread+0x80005a0030d8 ([kernel.kallsyms]) 7fffa67ef7bf ret_from_fork+0x80005a00301f ([kernel.kallsyms]) Xorg 6878 [000] 3373.464285: syscalls:sys_enter_ioctl: fd: 0x00000015, cmd: 0x0000641e, arg: 0x00000000 f8b67 __GI___ioctl+0xffff0148328c8007 (/usr/lib64/libc-2.23.so) 42b8 drmIoctl+0xffff01483010e028 (/usr/lib64/libdrm.so.2.4.0) 12888 qxl_enter_vt_kms+0xffff01483cd24028 (/usr/lib64/xorg/modules/drivers/qxl_drv.so) 37141 AddScreen+0xffffffffff800101 (/usr/libexec/Xorg) 7cf72 InitOutput+0xffffffffff8003c2 (/usr/libexec/Xorg) 3abd6 dix_main+0xffffffffff8001d6 (/usr/libexec/Xorg) 20731 __libc_start_main+0xffff0148328c80f1 (/usr/lib64/libc-2.23.so) 24d59 _start+0xffffffffff800029 (/usr/libexec/Xorg) xf86-video-ati for example seems to have more drmDropMaster() and drmClose() callers in cleanup/teardown paths. Seems like it might be a xf86-video-qxl bug? If so, I wonder why gdm users don't appear to see this. Might be because iirc they have per-user unprivileged Xorg processes and so they have some other code managing drm master transitions? Or perhaps they wait for the Xorg process to logout and terminate before switching vt? Or perhaps I'm misunderstanding the whole thing.
This is now the final unaddressed blocker for fedora 25, and we have the go/no go meeting on Thursday. Is there any progress on a fix for this?
Cc'ed ajax and airlied as this looks graphics-y, and Hans as he fixed a previous sddm vs. Qxl issue. Any ideas, guys? When I get home I'll try and confirm whether this is qxl-only.
I tested this here in a VM installed from Fedora-KDE-Live-x86_64-25-20161107.n.0.iso , with both qxl and vga adapters in the VM (using 'vga' results in the 'modeset' Xorg driver being used). I cannot reproduce the initially-described issue, as Kamil and Martin both found. Of Kamil's issues, I can reproduce "All sessions are killed if user2 logs out" (#c4) with qxl, but not with vga. I can reproduce "Only black screen instead of login screen is shown, if user1 logs out" (#c5) with both drivers. The scratch build referenced in #c15 - http://koji.fedoraproject.org/koji/taskinfo?taskID=16279725 - does fix "Only black screen instead of login screen is shown, if user1 logs out" (#c5), with both drivers. Since we have two separate issues here and a fix for one but not the other, I'm going to split this report for clarity, and (for now) apply the 'AcceptedBlocker' status to both. This report is now for the #c4 problem: "All sessions are killed if user2 logs out. Reproducer: 1. boot the system 2. log in with user1 3. switch to user2 4. log out user2 5. see that user1 has been logged out (or killed) as well. TTY2 is now empty (should not be). If you try to log in as user1, you get a new session (you should get back to the existing session). Sometimes I see an error flash about "kmserver could not be started" or something like that right before login screen is shown." I will file a new bug for the #c5 problem, and mark it POST since we appear to have a resolution for that. As things stand we are still not aware of any fix for this issue, though there are some PRs and commits upstream I want to look at.
https://bugzilla.redhat.com/show_bug.cgi?id=1392654 covers #c5.
So as a kinda hail mary, I tried a scratch build with this patch from upstream: https://github.com/sddm/sddm/pull/724 which implements logind support for sddm. Result of that seems to be that 'Switch User' goes away from the kicker entirely. Which, I mean, technically resolves the issue, but I'm not sure want to just say 'what the hell, let's go with that', as it's a pretty drastic change. Just figured I'd try something.
It may be worth noting that once the issue is triggered, further logins and logouts don't crash anything - everything seems to be fine.
except Boxes, crashing all the time I try to log in afterwards can that mean something? i guess the driver isn't dealing with it very well
Created attachment 1218540 [details] User session with a greeter as a window Ok, I may be mistaken in the pre-previous comment - seems the session stays alive at some times. This time it even survived the start of the greeter. And took it as a window under kwin.
Reassigning to xorg-x11-drv-qxl as it seems it's the root of the issue. If it's not, I hope we'll be able to find a solution together faster.
To add here, I did a install from Fedora-KDE-Live-x86_64-25-20161107.n.0.iso on a machine here. I created two users, mary and foo, I had no issues switching between them using the "switch user" menu option. on logout from mary's session I was returned to the password screen to unlock foo's session. in my testing on bare metal I did not hit either bug
I also just tried and could not reproduce this one on bare metal, so yeah, this one does look more and more to be tied to qxl.
I'm a clear +1 FE if a fix is found. On the other hand, user-switch is a less-common function (particularly under a VM), so I don't think it would pass the "last blocker at Go/No-Go" test (which it looks likely to actually have to face). So unless new information comes to light that says it happens outside of VMs, I'm going to vote -1 blocker.
Petr Schindler tested this on a bare metal and it also seems to work OK there. So yeah, probably qxl related. And in that case I'm also for -1 blocker.
One of the reasons GDM doesn't exhibit this could be in the fact it actually allocates VT1 for itself. SDDM leaves the VTs when a user session starts.
Discussed at mini blocker review during go/no-go meeting [1]. We re-evaluated this bug. This bug was rejected as Final Blocker and accepted as Freeze Exception - this is downgraded to FE as it only affects the qxl driver, and we think user switching is fairly rare in VMs (and also rare in live sessions, so the combination makes a post-release fix acceptable) [1] https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.html
Actually it looks like sddm isn't involved in the VT switching at all, it all happens in the xserver. In hw/xfree86/os-support/linux/lnx_init.c:xf86CloseConsole(), it calls the VT_SETMODE ioctl with VT.mode=VT_AUTO, so aiui the xserver isn't notified anymore when the VT changes. Then it "Perform[s] a switch back to the active VT when we were started". So the driver should have given up drm master by this point. As it hasn't, the xserver on the original active VT (VT1) falls over when it's notified of the VT switch and tries to use DRM_IOCTL_SET_MASTER. Other video drivers seem to define an xf86FreeScreenProc which ends up calling drmClose. Perhaps this is what is missing in the qxl driver? (I'm not entirely sure if or when this is called on xserver teardown though).
Reported upstream with a working (though not exhaustively tested) patch - https://bugs.freedesktop.org/show_bug.cgi?id=99102
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.