Red Hat Bugzilla – Bug 61743
Lock screen goes to graphical login prompt
Last modified: 2007-04-18 12:41:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314
Description of problem:
When locking the screen, either through time-delayed screen saver activation or
using the "Lock Screen" command in the KDE menu, the display "cycles" (clicks on
and off, as if changing resolution), and goes to the graphical login screen.
The selected screensaver doesn't come up, it just dumps out to this screen.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Login to KDE (I am using a graphical login after bootup)
2. "Lock Screen" or wait for screensaver to kick in
Actual Results: The display "cycles" (clicks on and off, as if changing
resolution), and goes to the graphical login screen. If I log in here as the
same user, it attempts to start up another KDE session. It loads the desktop,
but then most KDE programs (Kmail, Konqueror) don't work because they only like
one instance of themselves. Non-KDE programs such as Mozilla and Gaim open up
additional copies of themselves.
If I do not log in at this screen, and instead switch to a console
(ctrl-alt-F1), and then from there go back to X (alt-F7), the screensaver comes
up as expected.
Expected Results: The screensaver or blank screen should have come up.
This is a fresh install of Skipjack, with graphical login enabled. I haven't
tried it with text-mode login yet, or with Gnome; I'll try that soon.
Can't reproduce this with 3.0.0-1, assuming it's fixed.
I'm seeing this with a fresh skipjack install + up2date -u
jmm@jmm:/home/jmm> rpm -qf $(which kdm)
It's interesting - the lock screen actually isn't breaking the existing
virtual console. Basically what happens is:
- kdm starts on vt 7 as per normal runlevel 5
- user logs in
- user clicks lock screen (or any other method for getting to lock screen)
*** here's the critical part ***
- the kde / X on vt 7 *DOES LOCK THE SCREEN* just fine
- what happens is that a new kdm "instance" starts on vt 8 and the console is
switched over to vt 8. Specifically, an instance of "kdm_greet" is started.
- If the user switches back over to vt 7 (ctl+alt+f7) and unlocks the screen
then the kdm_greet on vt8 goes away
this effect does cascade as well, meaning if one user logs in to kdm on
vt7, locks the screen, another user then logs in to the kdm_greet kdm front
on vt8 and locks their screen, a kdm_greet happens on vt9 with vt7 and vt8
both locked. Once vt8 unlocks, the kdm_greet on vt9 goes away, then logging
out there and unlocking vt7 has the kdm_greet on vt8 go away.
*** note: random babbling coming up ***
I get the feeling at this point that it's a keyboard/mouse device access kind
of things going on - the process of locking the screen is doing something to
forcefully grab those devices and kdm (still running) picks that up as a
problem and starts the new kdm_greet.
Now, *potentially*, this is a very-much-intended feature so (say in a
university computer lab) someone can't make a machine's console worthless with
a locked session - a new kdm_greet starts and whoever walked away (just
locking the screen) is back. I could definitely see this being a very useful
feature. It'd be nice if it were confirurable if it's intentional, and even
better if it defaulted to no new kdm_greet so univ. computer labs could just
switch the config option and get this nice behavior for them while leaving it
as "lock and don't start a new kdm_greet" for the rest of us.
Created attachment 52130 [details]
specific processes created when the screen gets locked
hopefully the processes getting spawned will make the code path easier to
As another data point, if this sequence happens:
- normal boot, user logs into vt7, locks screen
- kdm_greet starts on vt8, diff (dunno if it can be the same) user logs in to
- switch to vt7, user unlocks
then at that point (vt8 has a running kde session), the vt7 user locking the
screen *DOES NOT* start a new kdm_greet and switch over - it just locks.
This is feeling more and more like a very intentional feature that would be
great to have but should be turned off by default :)
yup, it's intentional, and that's nice, but it should really be configurable.
$XDM_MANAGED is set for the fifo's that clients can talk to the running kdm
over. this is done in kdm's backend/client.c
(line 798 in ver 2.23)
kdesktop_lock parses this variable and picks the first entry (comma-separated)
as the fifo to send strings to. When it locks, it'll send "lock\n" (if not a
child screen saver) and sends "unlock\n" on unlock.
(lines 539, 565 of version 1.4)
when the display manager processes the lock message, he does exactly what I
guess - if all displays are locked, start a new greeter.
(lines 770-773 of version 1.36)
1) If you really can't reproduce this behavior to start with, that would seem
to indicate a bug that you're seeing since it seems obviously intended
2) as I said before, this is nice to have in many situations but should really
be configurable and default to not starting the reserve display (spawning a
kdm_greet). Looks like it'd be pretty simple to add that code.
anyone else seeing one of the comments as having an (apparently) very long
line? all I see from here is that the width of this page is now about 4x
of what it needs to be. I think there's another konqueror textarea bug
to be entered :)
(OT) I'm getting the long line displaying in Konqueror, but not Mozilla (the
page as rendered in Moz has normal width). I can't see very obviously where it
is showing up, but it's only the comment table that is wide.
the less-than-optimal-but-fixes-the-bug patch
--- kdebase/kdm/backend/dm.c.orig Wed Apr 3 20:52:34 2002
+++ kdebase/kdm/backend/dm.c Wed Apr 3 20:52:54 2002
@@ -772,2 +771,0 @@
- if (AllLocalDisplaysLocked (0))
- StartReserveDisplay (0);
for me, the bug disappeared since kdebase-3.0.0-2
I can not reproduce this problem with kdebase 3.0.0-2 (haven't tried older ones)
Make sure you use the current kdm config files (upgrading may have kept the old files
intact and put the new ones in as .rpmnew files, maybe that's why you've still seen this
after I've closed the report).
I'm on the "3.0.0-2 works for me" bandwagen as well.
confirmed fixed in 3.0.0-3