Screen Lock Error

[Duncan]

Zaki Akhmad posted on Wed, 11 Jul 2012 14:04:23 +0700 as excerpted:

> Once, I press Esc button, then the very-long password text is erased.
> But when this problem happened again, the Esc button didn't work.
> 
> How to see debug error message from this event?
> 
> So, my solution from this problem up till now is switch to terminal mode
> $
> sudo -i reboot :|


A reboot shouldn't be necessary.  Since you obviously know enough about 
the text terminals to login there and type that sudo, you should be able 
to type a few other commands there too, and at worst, kill and restart X, 
or more likely, just kill kde and let the login dialog (assuming you 
login from a *dm, kdm, xdm, gdm, whatever, a graphical login) reappear.  

Yet another alternative is to switch to a text login and start kde from 
there, turning off the graphical login (which I'm assuming you're using) 
entirely, so that if you kill kde from a text terminal, you just restart 
it from the same text terminal you killed it from.  Years ago after some 
problems with whatever *dm I was using at the time (Mandrake Linux, 
probably 8.x), I switched to text login, starting X and kde from there if 
desired, and never switched back to the GUI *dm, so that's exactly the 
solution I use today.

Try issuing this from your text terminal:

killall startkde

Since I actually use a text login and type a command from there that runs 
a wrapper script that sets a kde session and then runs startx to start it 
(which in turn runs startkde), I don't know for sure how the *dm 
graphical logins work these days, but I'm hoping they still use startkde 
to start the kde session.  If they do, then that should kill the session 
and return the X session to a normal graphical login screen.

If that doesn't work, you can try running killall startx, or killall 
<whatever dm you run>, or killall xorg-server, or something similar.  
However, those often run as root so you'd need to use sudo or the like.

Depending on how your distro has setup the *dm, that will likely kill it, 
but it will likely respawn with a graphical login.

Another alternative is to use your distro's service-restart commands (I 
don't know how systemd handles it, but on conventional init distros it's 
generally something like /etc/init.d/xdm restart, or rc-service xdm 
restart, or some such).  Of course those require privs and so probably 
sudo or whatever, as well.  If the graphical login doesn't respawn on its 
own after it's killed, this should work.


Finally, most distros provide a way to start whatever installed desktop 
session you want (kde in this case) from the commandline itself, thus 
letting you reconfigure the graphical login service to not even start at 
all, as you login at the text terminal and start X and whatever session 
from there if you want.  That's what I do here.

You'll need to do a bit of research on how your distro handles it, but 
here, it's a matter of setting/exporting the XSESSION environmental 
variable before running startx, and I've simply setup a wrapper with a 
single letter "k" name (easy to type), that sets it to kde before running 
startx.  That gets me an X session running kde direct from a text login.  
(When X starts it still switches to the normal X VT, #7 here, leaving my 
previous text login running on VT1 or whatever.)

With that setup, if X quits responding and I can still get to the text 
VT, I can simply type killall startkde from there, and it shuts down all 
of KDE and X, so I can restart it.  That's why I suggested trying that 
with the graphical login too, altho I'm not sure it works exactly the 
same there, the reason I explained the other options as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.