I started TDM with useSAK=false, uinput not loaded: * No Ctrl-Alt-Delete dialog * Warning message in KControl to enable evdev/uinput * Check box ghosted/disabled
I logged out. Loaded uinput. Restarted with init 4. * No warning message in KControl
Enabling the check box (and Apply): * tsak and tsak.lock appeared in /tmp/tdesocket-global/
Without logging out, disabling TSAK in KControl: * tsak and tsak.lock disappeared
During this time I never closed the TDM module.
I re-enabled TSAK through KControl and logged out. Upon logging in: * KControl check box was not enabled * tdmrc showed useSAK=true * tsak and tsak.lock appeared in /tmp/tdesocket-global/
After toggling the check box and selecting Apply, with the check box enabled, I toggled from the KControl TDM module to another KControl module and then immediately returned to the TDM module. The check box was not enabled.
To actually disable tsak I have to toggle the check box: "enable" and "disable" and then useSAK=false and the tsak and tsak.lock files disappeared.
I logged out with TSAK enabled (despite no check box). From a terminal I successfully killed all three tsak processes. Upon toggling back to TDM (Alt-F7) there was no Ctrl-Alt-Delete dialog. I logged in without no resistance. The tsak and tsak.lock files existed in /tmp/tdesocket-global because I did not delete them. The three tsak processes returned. I logged out and was greeted with the Ctrl-Alt-Delete dialog.
I repeated the process, but this time deleted the tsak and tsak.lock files too. I again logged in without resistance. This time there were no tsak processes running after I logged in. Apparently then tsak restarts if the FIFO files exist but does not restart if the FIFO files are deleted. useSAK=true the whole time. Upon logging out I was greeted with the Ctrl-Alt-Delete dialog. Therefore TDM must be restarting tsak.
I repeated this process including deleting the two FIFO files. I again logged in with no resistance. Then from the TDE menu I selected "Switch User." I was greeted with the Ctrl-Alt-Delete dialog.
Seems then whenever useSAK=true AND TDM receives direct focus that tsak is checked or restarted. TDM does not restart tsak with indirect focus as I accomplished.
This latest patch looks great. Much better housekeeping and when tsak is disabled in KControl, the effect is immediate and the housekeeping is immediate. Nice. :)
Summary:
* Glitch: KControl is not displaying the check box as enabled despite useSAK=true. Probably a forgotten or misplaced readEntry?
* Possible glitch: Seems TDM should restart tsak as soon as I logged in, despite my "malevolent" effort to disable tsak. However, as shown by the Switch User test, TDM immediately restarted tsak, and that probably is sufficient. Within the intent of how tsak should function (I don't know the specs), I'm unsure whether TDM should be polling the process list to immediately restart tsak when disabled as I circumvented. Seems to me that a user should not be able to do what I did. Even if I did not have a free console open, I could have accomplished the same with through SSH. Seems to me that as long as useSAK=true tsak should be a persistent little b-stard. :)
The desktop lockout bug remains (desktop icons and context menu disappear, can't logout), and the profile directories accrue like rabbits copulating, but this patch did not address those issues. :)
Darrell
<snip>
Summary:
- Glitch: KControl is not displaying the check box as enabled despite
useSAK=true. Probably a forgotten or misplaced readEntry?
This behaves that way on purpose--when useSAK=true and tsak cannot be enabled (i.e. when uinput is not loaded) the checkbox is not checked to avoid the appearance of tsak being permanently enabled. If this is confusing then we will need to find a better way to indicate this.
- Possible glitch: Seems TDM should restart tsak as soon as I logged in,
despite my "malevolent" effort to disable tsak. However, as shown by the Switch User test, TDM immediately restarted tsak, and that probably is sufficient. Within the intent of how tsak should function (I don't know the specs), I'm unsure whether TDM should be polling the process list to immediately restart tsak when disabled as I circumvented. Seems to me that a user should not be able to do what I did. Even if I did not have a free console open, I could have accomplished the same with through SSH. Seems to me that as long as useSAK=true tsak should be a persistent little b-stard. :)
I never really thought about this, but I guess this might be a correct way of looking at it. My original thought was that if someone killed tsak, all users would know that the system was compromised as the Ctrl+Alt+Del screens would not appear or function. Automatically restarting tsak might make more sense, but TDE's design doesn't make this particularly easy.
The desktop lockout bug remains (desktop icons and context menu disappear, can't logout), and the profile directories accrue like rabbits copulating, but this patch did not address those issues. :)
The desktop lock seems to be rather badly messed up in general. I need to figure out what happened to cause this; it probably broke in my earlier attempts to convert it to a persistent process.
Tim
- Glitch: KControl is not displaying the check
box as enabled despite useSAK=true. Probably a forgotten or misplaced readEntry?
This behaves that way on purpose--when useSAK=true and tsak cannot be enabled (i.e. when uinput is not loaded) the checkbox is not checked to avoid the appearance of tsak being permanently enabled. If this is confusing then we will need to find a better way to indicate this.
I did not explain myself well. After I loaded uinput and set useSAK=true the check box was not showing enabled. The check box did not show the correct status thereafter. The check box was always showing disabled, contrary to useSAK=true and uinput=loaded. Everything was working as I described, just the check box did not show the correct status.
I expect the check box to be ghosted when uinput is not loaded regardless of the status of useSAK, along with the warning message, and that all works.
- Possible glitch: Seems TDM should restart tsak as soon as I logged in,
despite my "malevolent" effort to disable tsak. However, as shown by the Switch User test, TDM immediately restarted tsak, and that probably is sufficient. Within the intent of how tsak should function (I don't know the specs), I'm unsure whether TDM should be polling the process list to immediately restart tsak when disabled as I circumvented. Seems to me that a user should not be able to do what I did. Even if I did not have a free console open, I could have accomplished the same with through SSH. Seems to me that as long as useSAK=true tsak should be a persistent little b-stard. :)
I never really thought about this, but I guess this might be a correct way of looking at it. My original thought was that if someone killed tsak, all users would know that the system was compromised as the Ctrl+Alt+Del screens would not appear or function. Automatically restarting tsak might make more sense, but TDE's design doesn't make this particularly easy.
I had not thought about that either. I suppose in any environment where sak was deemed necessary, there would be training that the dialog should always appear and when that does not happen to report to an admin. In such an environment, I doubt a single console would be open to have such access as I have on mine. If SSH was available in that environment then likely keys and passphrases both would be used, so pretty tough to hack tsak. Ignoring those oddball corner cases then means tsak is working as intended.
Ok, forget that. The check box needs to reflect the correct status after everything is enabled. Otherwise this patch is in the bag.
Darrell
- Glitch: KControl is not displaying the check
box as enabled despite useSAK=true. Probably a forgotten or misplaced readEntry?
This behaves that way on purpose--when useSAK=true and tsak cannot be enabled (i.e. when uinput is not loaded) the checkbox is not checked to avoid the appearance of tsak being permanently enabled. If this is confusing then we will need to find a better way to indicate this.
I did not explain myself well. After I loaded uinput and set useSAK=true the check box was not showing enabled. The check box did not show the correct status thereafter. The check box was always showing disabled, contrary to useSAK=true and uinput=loaded. Everything was working as I described, just the check box did not show the correct status.
This might have been due to the fact that the kcontrol module could write the reset useSAK=false key back to the config file if anything was saved. Try GIT hash b1e374b and see if the problem persists.
Tim
This might have been due to the fact that the kcontrol module could write the reset useSAK=false key back to the config file if anything was saved. Try GIT hash b1e374b and see if the problem persists.
Hmm. Sorry, the patch did not work. :(
useSAK=true and uinput loaded. TSAK is working as expected. The only glitch is the KControl check box does not reflect the true status, as shown in this screen grab:
http://humanreadable.nfshost.com/trinity/build_logs/tsak.png
Darrell
On Sunday 22 of April 2012 21:53:30 Darrell Anderson wrote:
This might have been due to the fact that the kcontrol module could write the reset useSAK=false key back to the config file if anything was saved. Try GIT hash b1e374b and see if the problem persists.
Hmm. Sorry, the patch did not work. :(
useSAK=true and uinput loaded. TSAK is working as expected. The only glitch is the KControl check box does not reflect the true status, as shown in this screen grab:
http://humanreadable.nfshost.com/trinity/build_logs/tsak.png
Darrell
Gee, and I was about to upload to PPA updated version 3.5.13 including the recent patches for SAK. Rather I wait (I cannot not test it now).
Slávek --
On Sunday 22 of April 2012 21:53:30 Darrell Anderson wrote:
This might have been due to the fact that the kcontrol module could write the reset useSAK=false key back to the config file
if
anything was saved. Try GIT hash b1e374b and see if the problem
persists.
Hmm. Sorry, the patch did not work. :(
useSAK=true and uinput loaded. TSAK is working as expected. The only glitch is the KControl check box does not reflect the true status, as shown in this screen grab:
http://humanreadable.nfshost.com/trinity/build_logs/tsak.png
Darrell
Gee, and I was about to upload to PPA updated version 3.5.13 including the recent patches for SAK. Rather I wait (I cannot not test it now).
Slávek
Bug fixed in GIT hash 06adb18. Sometimes it is better to look at things in the morning instead of late at night. ;-)
Tim
On 04/22/2012 06:49 PM, Timothy Pearson wrote:
Bug fixed in GIT hash 06adb18. Sometimes it is better to look at things in the morning instead of late at night. ;-)
Tim
Amazing how that works :p
We could jump off into the physiological processes at work after sleep unhinges your brain -- but we digress... Suffice it to say, sleep an underrated necessity :)
On Monday 23 of April 2012 01:49:59 Timothy Pearson wrote:
Hmm. Sorry, the patch did not work. :(
useSAK=true and uinput loaded. TSAK is working as expected. The only glitch is the KControl check box does not reflect the true status, as shown in this screen grab:
http://humanreadable.nfshost.com/trinity/build_logs/tsak.png
Darrell
Gee, and I was about to upload to PPA updated version 3.5.13 including the recent patches for SAK. Rather I wait (I cannot not test it now).
Slávek
Bug fixed in GIT hash 06adb18. Sometimes it is better to look at things in the morning instead of late at night. ;-)
Tim
Hmm, well I should go to sleep ... and I almost backporting the patch also made a mistake. (Specifically - tdm forgot to change to kdm.) :)
Slavek --
Bug fixed in GIT hash 06adb18. Sometimes it is better to look at things in the morning instead of late at night. ;-)
Been there, done that! :)
Latest patch:
http://humanreadable.nfshost.com/trinity/build_logs/tsak.png
Yay!
Regarding the original list of TSAK/TDM issues I posted Wednesday, 18 April. We have made great progress and the following list is muuuuuuuuch shorter. :)
* TSAK demands 90-100% CPU / High CPU consumption on wait SAK. Need testing by those who reported the problem. (I never experienced the problem.)
* xsession message of "[kdesktop] SAK driven secure dialog is not available for use (retcode %d)" appears although TDM is not running when using startx.
* When starting X from startx (TDM is not running) the message "tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'" appears. There should be no tdmctl/TSAK related messages when using startx.
* Both calls to tdmctl in tdmtsak use the format "tdmctl list" yet there is no "list" option in tdmctl --help. What is the "list" parameter supposed to do?
* TDM creates nominal profile directories in /tmp. All such directories use a numeric name string. TDM runs as non-user, but should not be creating any profile directories. Not needed and the profile directories are never purged. Never happened in KDE3.
================================================== Bug reports involved:
928, kdm starts too early 925, [kdesktop] SAK driven secure dialog is not available for use 906, SAK realization is mostly buggy for KDM 898, tsak process taking 90-100% of CPU 894, TDM: Log file is never purged 884, tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket' 667, kdm spawns kwin as root, keeps running after login 625, KDM is hard-coded to use /tmp rather than $TMP or $TMPDIR
Thanks Tim!
Darrell
Bug fixed in GIT hash 06adb18. Sometimes it is better to look at things in the morning instead of late at night. ;-)
Been there, done that! :)
Latest patch:
http://humanreadable.nfshost.com/trinity/build_logs/tsak.png
Yay!
Regarding the original list of TSAK/TDM issues I posted Wednesday, 18 April. We have made great progress and the following list is muuuuuuuuch shorter. :)
- TSAK demands 90-100% CPU / High CPU consumption on wait SAK. Need testing by those who reported the problem. (I never experienced the
problem.)
- xsession message of "[kdesktop] SAK driven secure dialog is not
available for use (retcode %d)" appears although TDM is not running when using startx.
This is debug spew from kdesktop and should be ignored unless you are trying to debug the Secure Dialog/Desktop Lock system. The best way to fix this is probably to make the printf() into a kdDebug so that it does not pollute .xsession_errors. Thoughts?
- When starting X from startx (TDM is not running) the message "tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'" appears. There should be no tdmctl/TSAK related messages when using
startx.
- Both calls to tdmctl in tdmtsak use the format "tdmctl list" yet there
is no "list" option in tdmctl --help. What is the "list" parameter supposed to do?
IIRC "list" forces tdm to list all active sessions. It may be undocumented, but is used internally in the code.
- TDM creates nominal profile directories in /tmp. All such directories
use a numeric name string. TDM runs as non-user, but should not be creating any profile directories. Not needed and the profile directories are never purged. Never happened in KDE3.
This is due to twin as I mentioned earlier. In order to provide a managed window environment for TDM twin has to be launched, and twin expects to see DCOP running, so it is launched as well. The "profile directory" created consists of a number of DCOP sockets and related files. I do not yet know what the best way to deal with this is.
I have also repaired the desktop lock in GIT hash 50739c9--you should no longer have the desktop and icon problems you were experiencing earlier. If they do persist please let me know!
Tim
- xsession message of "[kdesktop] SAK driven secure dialog is not
available for use (retcode %d)" appears although TDM is not running when using startx.
This is debug spew from kdesktop and should be ignored unless you are trying to debug the Secure Dialog/Desktop Lock system. The best way to fix this is probably to make the printf() into a kdDebug so that it does not pollute .xsession_errors. Thoughts?
Sure. My focus for the bug report is to reduce xsession log clutter. When starting X from the command line, TDM and TSAK play no role in the Trinity session. When TDM is not running, which is the case in command line login mode, the error message appears. Thus to see those messages is confusing to most people. If converting the printf to kdDebug solves the problem then fine, but makes more sense to me for a simple sanity check for the TDM process before spewing the message.
- When starting X from startx (TDM is not running) the message "tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'" appears. There should be no tdmctl/TSAK related messages when using
startx.
Likewise with this message. The message only appears in command line login mode because TDM is again not running. I have yet to see the message when testing in graphical login mode.
- TDM creates nominal profile directories in /tmp. All such directories
use a numeric name string. TDM runs as non-user, but should not be creating any profile directories. Not needed and the profile directories are never purged. Never happened in KDE3.
This is due to twin as I mentioned earlier. In order to provide a managed window environment for TDM twin has to be launched, and twin expects to see DCOP running, so it is launched as well. The "profile directory" created consists of a number of DCOP sockets and related files. I do not yet know what the best way to deal with this is.
Okay. So we chew on that a bit. The band-aid solution is a cleanup script but that does not help people who seldom reboot their systems. Doesn't fix the root cause either. I don't know what changed from kwin->twin or what changed in the relationship between TDM/twin from KDM/kwin to need these dcop sockets or why creating these sockets needs to create user profiles. :)
Darrell
I have also repaired the desktop lock in GIT hash 50739c9--you should no longer have the desktop and icon problems you were experiencing earlier. If they do persist please let me know!
After rebuilding this took a long while to test because I could not discover any repeatable patterns. Because of that, the testing was confusing.
Here is what happens on my desktop with the latest patches.
============================================ When in graphical login mode and TSAK enabled:
* Pressing Ctrl-Alt-Delete causes a Secure Desktop Area dialog to appear. Because of the nature of the process I could not grab a screen image. Here is an image with my digital camera:
http://humanreadable.nfshost.com/trinity/build_logs/tde-lock-4.png
* The Switch User and Logoff Menu buttons are ghosted/disabled. I don't know how to enable or why they are disabled.
* When I tested as root, the image shows that no user ID is listed as who has the session locked. Perhaps that is intentional, but looks unprofessional. If the intent is to hide that root is logged in then the absence of a user name is a clue anyway.
* Selecting the "Lock Session" button, and proceeding through the process of restoring the desktop, still causes the desktop icons to disappear, the desktop context menu to stop functioning.
* Contrary to my previous report, I can log out. The process requires about 30 seconds or more to unfold, which is why I did not notice previously --- I did not wait that long.
* The disappearing acts are not repeatable. Sometimes the session restored with no ill effects.
* Selecting the Task Manager or Cancel buttons always cause the same ill effects. I never got the session to restore normally after using either button.
* The desktop remains usable. I can still use the panel icons, TDE menu, shortcuts, etc.
* For the first time I witnessed the CPU hogging reported by others. I saw this hogging only once when I invoked the Secure Desktop Area dialog. The moment I invoked the dialog by selecting the "Lock Session" button, the mouse pointer turned to an hourglass and my conky CPU usage ramped to about 68% while the frequency ramped from idle to full speed.
* The CPU hogging is not repeatable. I saw the behavior only once.
* Selecting the Lock applet icon works differently: causing the TSAK Ctrl-Alt-Delete dialog to appear immediately. I found this inconsistent and therefore confusing. I would have thought the Lock icon would invoke the "Secure Desktop Area" dialog.
* Using the Lock applet icon results in the same loss of functionality.
* I preset my screen saver to 1 minute and while in Lock Session mode the screen saver activated as expected.
============================================ When in graphical login mode and TSAK disabled (useSAK=false, uinput not loaded):
* Pressing Ctrl-Alt-Delete exits the session to TDM.
* In this mode the only method to lock the desktop is to use the Lock applet icon (or shortcut). Unlike KDE3, selecting the Lock applet icon does not cause the screen saver to immediately activate. Instead, a "Desktop Session Locked" dialog appears immediately. The screen saver does not activate until the expected setting timeout. Image:
http://humanreadable.nfshost.com/trinity/build_logs/tde-unlock-4.png
* Same ill effects and I can log out but the logout process takes a long time, about 30 seconds.
* The Cancel button is always ghosted.
* I am not able to again to lock the session.
* There are a bunch of dcop socket files in /tmp/.ICE-unix.
============================================ When in command line login mode:
* Pressing Ctrl-Alt-Delete exits the session to the command line.
* In this mode the only method to lock the desktop is to use the Lock applet icon (or shortcut). Unlike KDE3, selecting the Lock applet icon does not cause the screen saver to immediately activate. Instead a "Desktop Session Locked" dialog appears immediately. The screen saver does not activate until the expected setting timeout. Image:
http://humanreadable.nfshost.com/trinity/build_logs/tde-unlock-3.png
* The "Desktop Session Locked" dialog Cancel button is ghosted/disabled.
* Typing my password restores the desktop, but:
* Just before the "Desktop Session Locked" dialog appears, sometimes I momentarily saw the TSAK Ctrl-Alt-Delete dialog.
* tdmrc:useSAK=false during these tests. Besides, this is command line mode, and TSAK should never be involved.
* Most often upon restoring the desktop, like before, desktop icons disappeared, the desktop context menu ceased to function.
* Occasionally, when the desktop icons did not disappear and the desktop context menu still functioned, before returning to the desktop I was always presented with the "Desktop Session Locked" dialog multiple times. Sometimes the dialog reappeared only once, but sometimes more often.
* I can log out but the logout process takes a long time, about 30 seconds.
* Always I am not able to again to lock the session.
============================================ With both the graphical login mode with TSAK disabled and command line login:
* Sometimes two pipe files in appeared /tmp/tdesocket-global: kdesktoplockcontrol and kdesktoplockcontrol_out. They do not disappear when the screen is unlocked. Looks like some more housekeeping needed.
* The two pipe files did not always appear. I don't know the pattern to repeat.
* Seems to me that in these two modes, when TSAK should be out of the picture (but possibly inadvertently isn't), the process should work exactly the same as in KDE3, except with different dialogs: screen saver and then dialog.
* The Cancel button in all dialogs should be enabled all the time.
============================================
Overall, I am unable to discern patterns to repeat the events I am sharing. Hence the ugly report. Let me know what further testing you want or need. Testing this locking mechanism is one of the more time consuming tests because of the weird events, which require restarting the session because only one lock is allowed and then the feature stops working.
Darrell
I have also repaired the desktop lock in GIT hash 50739c9--you should no longer have the desktop and icon problems you were experiencing earlier. If they do persist please let me know!
After rebuilding this took a long while to test because I could not discover any repeatable patterns. Because of that, the testing was confusing.
Here is what happens on my desktop with the latest patches.
============================================ When in graphical login mode and TSAK enabled:
- Pressing Ctrl-Alt-Delete causes a Secure Desktop Area dialog to appear.
Because of the nature of the process I could not grab a screen image. Here is an image with my digital camera:
http://humanreadable.nfshost.com/trinity/build_logs/tde-lock-4.png
- The Switch User and Logoff Menu buttons are ghosted/disabled. I don't
know how to enable or why they are disabled.
<snip>
They are not yet implemented.
Overall, I am unable to discern patterns to repeat the events I am sharing. Hence the ugly report. Let me know what further testing you want or need. Testing this locking mechanism is one of the more time consuming tests because of the weird events, which require restarting the session because only one lock is allowed and then the feature stops working.
This is VERY odd. Can you look in your .xsession_errors log after the desktop lock stops working and see if there are any odd messages in there?
Tim
I have also repaired the desktop lock in GIT hash 50739c9--you should no longer have the desktop and icon problems you were experiencing earlier. If they do persist please let me know!
After rebuilding this took a long while to test because I could not discover any repeatable patterns. Because of that, the testing was confusing.
Here is what happens on my desktop with the latest patches.
============================================ When in graphical login mode and TSAK enabled:
- Pressing Ctrl-Alt-Delete causes a Secure Desktop Area dialog to
appear. Because of the nature of the process I could not grab a screen image. Here is an image with my digital camera:
http://humanreadable.nfshost.com/trinity/build_logs/tde-lock-4.png
- The Switch User and Logoff Menu buttons are ghosted/disabled. I don't
know how to enable or why they are disabled.
<snip>
They are not yet implemented.
Overall, I am unable to discern patterns to repeat the events I am sharing. Hence the ugly report. Let me know what further testing you want or need. Testing this locking mechanism is one of the more time consuming tests because of the weird events, which require restarting the session because only one lock is allowed and then the feature stops working.
This is VERY odd. Can you look in your .xsession_errors log after the desktop lock stops working and see if there are any odd messages in there?
Tim
The steps to replicate the desktop icon problem are: 1.) Set the screen saver interval to something short like 1 minute 2.) Wait for screen saver to activate 3.) Move mouse. Viola, icons are now gone.
Working on this...
Tim
The steps to replicate the desktop icon problem are: 1.) Set the screen saver interval to something short like 1 minute 2.) Wait for screen saver to activate 3.) Move mouse. Viola, icons are now gone.
Working on this...
I'm about to return to my testing, but for me, I did not have to wait for the screen saver to activate.
All I needed was to invoke the lock and then immediately restore.
Darrell
The steps to replicate the desktop icon problem are: 1.) Set the screen saver interval to something short like 1 minute 2.) Wait for screen saver to activate 3.) Move mouse. Viola, icons are now gone.
Working on this...
I'm about to return to my testing, but for me, I did not have to wait for the screen saver to activate.
All I needed was to invoke the lock and then immediately restore.
Darrell
You probably have your system configured with a lock delay, correct? The issue seems to be in the code that is triggered before the screen is actually locked with a password.
Tim
The steps to replicate the desktop icon problem are: 1.) Set the screen saver interval to something short like 1 minute 2.) Wait for screen saver to activate 3.) Move mouse. Viola, icons are now gone.
Working on this...
I'm about to return to my testing, but for me, I did not have to wait for the screen saver to activate.
All I needed was to invoke the lock and then immediately restore.
Darrell
You probably have your system configured with a lock delay, correct? The issue seems to be in the code that is triggered before the screen is actually locked with a password.
Tim
Never mind, I can't seem to reliably trigger the problem now. Suffice it to say that I am continuing to work on it, and that further testing on your end of this problem at this time is likely a waste of time. :-)
Tim
The steps to replicate the desktop icon problem are: 1.) Set the screen saver interval to something short like 1 minute 2.) Wait for screen saver to activate 3.) Move mouse. Viola, icons are now gone.
Working on this...
I'm about to return to my testing, but for me, I did not have to wait for the screen saver to activate.
All I needed was to invoke the lock and then immediately restore.
Darrell
You probably have your system configured with a lock delay, correct? The issue seems to be in the code that is triggered before the screen is actually locked with a password.
Tim
Never mind, I can't seem to reliably trigger the problem now. Suffice it to say that I am continuing to work on it, and that further testing on your end of this problem at this time is likely a waste of time. :-)
Tim
Some additional information: one symptom of this problem is kdesktop_lock not exiting properly and going zombie, e.g. ps aux | grep kdesktop_lock shows something like user <pid> 1.1 0.0 0 0 ? Z 14:45 0:00 [kdesktop_lock] <defunct>
This indicates a problem in kdesktop itself.
Tim
The steps to replicate the desktop icon problem are: 1.) Set the screen saver interval to something short like 1 minute 2.) Wait for screen saver to activate 3.) Move mouse. Viola, icons are now gone.
Working on this...
I'm about to return to my testing, but for me, I did not have to wait for the screen saver to activate.
All I needed was to invoke the lock and then immediately restore.
Darrell
You probably have your system configured with a lock delay, correct? The issue seems to be in the code that is triggered before the screen is actually locked with a password.
Tim
Never mind, I can't seem to reliably trigger the problem now. Suffice it to say that I am continuing to work on it, and that further testing on your end of this problem at this time is likely a waste of time. :-)
Tim
Some additional information: one symptom of this problem is kdesktop_lock not exiting properly and going zombie, e.g. ps aux | grep kdesktop_lock shows something like user <pid> 1.1 0.0 0 0 ? Z 14:45 0:00 [kdesktop_lock] <defunct>
This indicates a problem in kdesktop itself.
Tim
This *should* be fixed in GIT hash 67a3a8f. Under specific circumstances when kdesktop was signalled on lock exit, specifically if xcb was currently executing an operation, kdesktop could wedge irrecoverably.
Tim
Some additional information: one symptom of this problem is kdesktop_lock not exiting properly and going zombie, e.g. ps aux | grep kdesktop_lock shows something like user <pid> 1.1 0.0 0 0 ? Z 14:45 0:00 [kdesktop_lock] <defunct>
This indicates a problem in kdesktop itself.
I tested again with the latest patch for a race condition.
The patch has stabilized just about everything. :)
No more desktop icon disappearance.
The desktop context menu works.
Alt-F2 works.
I can logout using any option.
No misbehavior when selecting the Task Manager or Cancel buttons.
Comments:
* I still notice the tsak Ctrl-Alt-Delete dialog appearing momentarily before the Desktop Session Locked dialog appears. I think a slower system is needed to see this, like a VM, because I can't see the dialog when running on my regular hardware. I doubt the dialog appearing is good or intentional. Especially when I see the dialog in command line login mode, which means tsak is not supposed to be in the picture at all. Not to mention that appearing momentarily like that does not look "high quality." :)
* All dialogs appear before the screen saver. I don't know that this is incorrect or bad, but is the opposite behavior of KDE3 and will require long-time users time to grow accustomed.
* For years I have used Ctrl-Alt-Delete as my logout shortcut. That shortcut works except when useSAK=true. The missing element is the Logout button is ghosted/disabled in the dialog. You mentioned that the feature has not been implemented, but seeing that feature added will be nice. :)
* As mentioned previously, the Secure Desktop Area dialog does not show root's account name in the dialog. Just the single quotation marks with nothing in between.
* When the Secure Desktop Area dialog appears, and after selecting the Lock Session button, the mouse pointer turns to an hour glass. I think many users will find that confusing. That "busy" mouse pointer indicates something is going to happen, that the system is busy doing something. The inclination for the user is to wait for the "busy" condition to dissipate because that is what users are accustomed to doing. Yet nothing ever happens until the user bumps the mouse or presses a keyboard key. The busy pointer doesn't feel right. Perhaps instead of the busy pointer, the screen saver should activate immediately. Immediately activating the screen saver also provides feedback that the system is locked because that is how the process functioned in KDE3 and other desktops.
* I have not yet seen the CPU hogging issue return but others who witnessed that mystery will have to test further. I saw that happen only once.
Good job with the patch!
Darrell
You probably have your system configured with a lock delay, correct? The issue seems to be in the code that is triggered before the screen is actually locked with a password.
I don't know. Where is this configuration option?
Darrell
This is VERY odd. Can you look in your .xsession_errors log after the desktop lock stops working and see if there are any odd messages in there?
Another symptom of this bug: Alt-F2 will not launch the minicli and I can't run the minicli from the TDE menu.
I noticed the most recent patch addressing a race condition. I am rebuilding and will test again. For now:
xsession log output (ignoring standard messages):
======================================================= graphical login, useSAK=true, uinput loaded, pressing Ctrl-Alt-Delete:
Couldn't get a file descriptor referring to the console WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error [twin] X_SetInputFocus(0xe00017): BadMatch (invalid parameter attributes)
======================================================= graphical login, useSAK=true, uinput loaded, selecting the Lock applet icon:
Couldn't get a file descriptor referring to the console WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error
======================================================= graphical login, useSAK=false, uinput not loaded, selecting the Lock applet icon:
WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error
======================================================= command line login, useSAK=false, uinput not loaded, selecting the Lock applet icon:
WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error
=======================================================
Darrell
-
Darrell Anderson -
David C. Rankin -
Slávek Banko -
Timothy Pearson