Bug 61743 - Lock screen goes to graphical login prompt
Lock screen goes to graphical login prompt
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: kdebase (Show other bugs)
skipjack-beta1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: wdovlrrw
Ben Levenson
:
Depends On:
Blocks: 61590
  Show dependency treegraph
 
Reported: 2002-03-23 18:58 EST by Brian Salomaki
Modified: 2007-04-18 12:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-04 10:40:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
specific processes created when the screen gets locked (552 bytes, text/plain)
2002-04-03 15:55 EST, James Manning
no flags Details

  None (edit)
Description Brian Salomaki 2002-03-23 18:58:55 EST
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):


How reproducible:
Always

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.

Additional info:

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.
Comment 1 Bernhard Rosenkraenzer 2002-03-27 11:08:48 EST
Can't reproduce this with 3.0.0-1, assuming it's fixed.
Comment 2 James Manning 2002-04-03 13:56:02 EST
I'm seeing this with a fresh skipjack install + up2date -u 
 
jmm@jmm:/home/jmm> rpm -qf $(which kdm) 
kdebase-3.0.0-0.cvs20020321.1 
 
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.
Comment 3 James Manning 2002-04-03 15:55:07 EST
Created attachment 52130 [details]
specific processes created when the screen gets locked
Comment 4 James Manning 2002-04-03 15:59:49 EST
hopefully the processes getting spawned will make the code path easier to 
find. 
 
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 
vt8 
- 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 :)
Comment 5 James Manning 2002-04-03 18:29:58 EST
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 
 
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdm/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. 
 
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdesktop/lock/lockprocess.cc 
 
(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. 
 
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdm/backend/dm.c 
 
(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.
Comment 6 James Manning 2002-04-03 18:35:04 EST
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 :)
Comment 7 Brian Salomaki 2002-04-03 21:08:11 EST
(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.
Comment 8 James Manning 2002-04-03 21:31:25 EST
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);
Comment 9 Harald Hoyer 2002-04-04 05:06:17 EST
for me, the bug disappeared since kdebase-3.0.0-2
Comment 10 Trond Eivind Glomsrxd 2002-04-04 10:40:47 EST
I can not reproduce this problem with kdebase 3.0.0-2 (haven't tried older ones)
Comment 11 Bernhard Rosenkraenzer 2002-04-04 11:02:14 EST
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). 
Comment 12 Jay Turner 2002-04-04 15:12:10 EST
I'm on the "3.0.0-2 works for me" bandwagen as well.
Comment 13 James Manning 2002-04-05 16:49:16 EST
confirmed fixed in 3.0.0-3

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