[Bug 979775] New: KDE session duplication
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 Bug ID: 979775 Summary: KDE session duplication Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs@opensuse.org Reporter: floux.dp@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- When I lock my session, I am able to create a new one with the already logged user. It seems weird. After that, I can still unlock the first session but cannot lock it anymore. At this moment, my screen becomes black with a message saying something like "It is impossible to lock your session, press CTRL+ALT+F2 then execute this command 'loginctl unlick-sessions' and then press CTRL+ALT+F7". -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c1 Stakanov Schufter <stakanov@freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stakanov@freenet.de --- Comment #1 from Stakanov Schufter <stakanov@freenet.de> --- I can confirm this bug. Instead, I cannot(!) open a second session of the same user. The opening session appears to abort and you drop back to the original session - which is, I am suspecting, what happens to the O.P. However, the behaviour described by the O.P. is the same. It can be easily triggered and reproduced. On my intel based system the reproducibility is 100%. My settings are: secure settings Create two user e.g. A and B Log into A Log into A again (will fail, you drop back to A). Log into B Now work a while into B. When you try to switch back to user A the screen lock will have crashed and the message comes up: screen lock has been damaged, switch to a terminal and unlock it with loginctl unlock-sessions. Of course with my settings in order to do that you have to be su. Now try to go back to B. Work a bit, return. Same scenario. This will repeat endlessly (a leech) until you logout user A. Than log in again. Now magically all is O.K. and the crash will not reproduce any more. In all this time, either screenlock of B and session are normal. Thus, if you work all the time in A, you will not even know about the issue as le lock of B is normal and A will not lock. It is somewhat minor as an issue but it would be nice to have this fixed for Leap 42.2. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c2 Daniel Velázquez <oximoron@gmx.es> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |oximoron@gmx.es --- Comment #2 from Daniel Velázquez <oximoron@gmx.es> --- It still remains in Tumbleweed. https://forums.opensuse.org/showthread.php/518831-The-screen-locker-is-broke... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c5 Karl Cheng <qantas94heavy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qantas94heavy@gmail.com Version|Leap 42.1 |Leap 42.3 --- Comment #5 from Karl Cheng <qantas94heavy@gmail.com> --- Thanks, moving to Leap 42.3. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c6 Fabian Vogt <fabian@ritter-vogt.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fabian@ritter-vogt.de --- Comment #6 from Fabian Vogt <fabian@ritter-vogt.de> --- Yes, logging in as the same user twice with a graphical session will not work due to reuse of the same session bus. However, this should be fixed in Leap 15/TW with the newer sddm version, which tries to switch to an existing session first. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c7 Stakanov Schufter <stakanov@freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Leap 42.3 |Leap 15.0 --- Comment #7 from Stakanov Schufter <stakanov@freenet.de> --- Now updating this to Leap 15 were I was able to reproduce the same bug. Thus valid for Leap 15 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c8 Fabian Vogt <fabian@ritter-vogt.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(stakanov@freenet. | |de) --- Comment #8 from Fabian Vogt <fabian@ritter-vogt.de> --- (In reply to Stakanov Schufter from comment #7)
Now updating this to Leap 15 were I was able to reproduce the same bug. Thus valid for Leap 15
Does it work with [Users] ReuseSession=true in /etc/sddm.conf? I'm not sure why it's not the default. If not, this might be a side effect of bug 1089287. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c9 Stakanov Schufter <stakanov@freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(stakanov@freenet. | |de) | --- Comment #9 from Stakanov Schufter <stakanov@freenet.de> --- (In reply to Fabian Vogt from comment #8)
(In reply to Stakanov Schufter from comment #7)
Now updating this to Leap 15 were I was able to reproduce the same bug. Thus valid for Leap 15
Does it work with
[Users] ReuseSession=true
in /etc/sddm.conf?
I'm not sure why it's not the default. If not, this might be a side effect of bug 1089287.
A few more info: before(!) the suggested change you have also the following side effect (kicking in even before you are presented with "the logscreen has been damaged"): you are not able to log out any more of the respective session. Second note: the system is a complete reinstall (not even /home left, was imported afterwards from a backup). I mention this, because the /etc/sddm.conf was completely empty prior to my intervention. Should it be filled with complete default conf-file then there is a bug, that will have to be addressed. After putting the above [Users]ReuseSession=true you have: the system does not allow any more the same user to login when choosing open new user session, it simply claims that the password is wrong or the login did not succeed. This is good, as it avoids you the above mentioned issue, thank you very much for this. Further the damaged logscreen: I will now wait idle for some time and then switch to the respective test session. Then I will update you if the issue represents with the setting or not (that means, if it damages although now you do not login). Will put the info below later on. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c10 --- Comment #10 from Stakanov Schufter <stakanov@freenet.de> --- So, it seems that the screenlock does not crash, but there is an unpleasant side effect. Take a three user environment. Start user A first session (tty7) Start user B second session (tty8) Start user B session again (to test) This will drop you right away to the open desktop of the second user, but(!) that is not all. The system will open an "unused session" in the list. Start now the third user C session. You will log in normally but when you try to use alt+ctl+fn to switch between the sessions there you will encounter that: A is on tty7 B is on tty8 C is on tty 10 (!) tty9 is locked, shows a sddm login screen (but default - that is before any user logged on) and does not allow to login any user. Thus the tty order is not respected and the user that should be on tty9 is on 10 (and you loose one screen as it is locked and unusable). So the solution is IMO sub-optimal because who is landing on that tty will think his account is wrong as he gets no error message specific to not being able to log in. What you can note during all this: the user C, when opened after the test of "doubling" the session of user B will open in a sluggish mode (takes longer) will show shortly the system messages that are normally on tty10 by default). Then you have the user opened on tty10, tty9 is locked. tty11 and 12 are blacked out, so you do not have the commodity of system messages any more. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c11 --- Comment #11 from Fabian Vogt <fabian@ritter-vogt.de> --- (In reply to Stakanov Schufter from comment #10)
So, it seems that the screenlock does not crash, but there is an unpleasant side effect. Take a three user environment. Start user A first session (tty7) Start user B second session (tty8) Start user B session again (to test) This will drop you right away to the open desktop of the second user, but(!) that is not all. The system will open an "unused session" in the list. Start now the third user C session. You will log in normally but when you try to use alt+ctl+fn to switch between the sessions there you will encounter that: A is on tty7 B is on tty8 C is on tty 10 (!)
tty9 is locked, shows a sddm login screen (but default - that is before any user logged on) and does not allow to login any user. Thus the tty order is not respected and the user that should be on tty9 is on 10 (and you loose one screen as it is locked and unusable).
So the solution is IMO sub-optimal because who is landing on that tty will think his account is wrong as he gets no error message specific to not being able to log in.
Note that all of ^ is irrelevant as long as bug 1089287 is not fixed.
What you can note during all this: the user C, when opened after the test of "doubling" the session of user B will open in a sluggish mode (takes longer) will show shortly the system messages that are normally on tty10 by default). Then you have the user opened on tty10, tty9 is locked. tty11 and 12 are blacked out, so you do not have the commodity of system messages any more.
That'd be a systemd bug. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c12 Stakanov Schufter <stakanov@freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(fabian@ritter-vog | |t.de) --- Comment #12 from Stakanov Schufter <stakanov@freenet.de> --- (In reply to Fabian Vogt from comment #11)
(In reply to Stakanov Schufter from comment #10)
So, it seems that the screenlock does not crash, but there is an unpleasant side effect. Take a three user environment. Start user A first session (tty7) Start user B second session (tty8) Start user B session again (to test) This will drop you right away to the open desktop of the second user, but(!) that is not all. The system will open an "unused session" in the list. Start now the third user C session. You will log in normally but when you try to use alt+ctl+fn to switch between the sessions there you will encounter that: A is on tty7 B is on tty8 C is on tty 10 (!)
tty9 is locked, shows a sddm login screen (but default - that is before any user logged on) and does not allow to login any user. Thus the tty order is not respected and the user that should be on tty9 is on 10 (and you loose one screen as it is locked and unusable).
So the solution is IMO sub-optimal because who is landing on that tty will think his account is wrong as he gets no error message specific to not being able to log in.
Note that all of ^ is irrelevant as long as bug 1089287 is not fixed.
What you can note during all this: the user C, when opened after the test of "doubling" the session of user B will open in a sluggish mode (takes longer) will show shortly the system messages that are normally on tty10 by default). Then you have the user opened on tty10, tty9 is locked. tty11 and 12 are blacked out, so you do not have the commodity of system messages any more.
That'd be a systemd bug.
Should I file that part of the bug against systemd or should I wait for bug 1089287 being fixed? (In reply to Fabian Vogt from comment #11)
(In reply to Stakanov Schufter from comment #10)
So, it seems that the screenlock does not crash, but there is an unpleasant side effect. Take a three user environment. Start user A first session (tty7) Start user B second session (tty8) Start user B session again (to test) This will drop you right away to the open desktop of the second user, but(!) that is not all. The system will open an "unused session" in the list. Start now the third user C session. You will log in normally but when you try to use alt+ctl+fn to switch between the sessions there you will encounter that: A is on tty7 B is on tty8 C is on tty 10 (!)
tty9 is locked, shows a sddm login screen (but default - that is before any user logged on) and does not allow to login any user. Thus the tty order is not respected and the user that should be on tty9 is on 10 (and you loose one screen as it is locked and unusable).
So the solution is IMO sub-optimal because who is landing on that tty will think his account is wrong as he gets no error message specific to not being able to log in.
Note that all of ^ is irrelevant as long as bug 1089287 is not fixed.
What you can note during all this: the user C, when opened after the test of "doubling" the session of user B will open in a sluggish mode (takes longer) will show shortly the system messages that are normally on tty10 by default). Then you have the user opened on tty10, tty9 is locked. tty11 and 12 are blacked out, so you do not have the commodity of system messages any more.
That'd be a systemd bug.
Should I file a separate bug or is this also dependent on the fix for bug 1089287? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=979775 http://bugzilla.opensuse.org/show_bug.cgi?id=979775#c13 Fabian Vogt <fabian@ritter-vogt.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fabian@ritter-vog | |t.de) | --- Comment #13 from Fabian Vogt <fabian@ritter-vogt.de> --- (In reply to Stakanov Schufter from comment #12)
Should I file a separate bug or is this also dependent on the fix for bug 1089287?
That's totally independent. My guess is that systemd doesn't set tty10 into exclusive mode. It might be intentional. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com