Potentially related to bug: 884

The following likely all are related:

884 tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'
898 tsak process taking 90-100% of CPU
906 SAK realization is mostly buggy for KDM
925 [kdesktop] SAK driven secure dialog is not available for use

Just to update. This problem still exists in R14 code as of 3/29. Using TDM, tsak & tdmtsak will consume 100% of cpu. Launching with startx does not exhibit this problem.

When launching from TDM, and after killing tsak "sudo killall tsak", tdmtsak continues to run and consumes ~20% of cpu by itself. Killing tdmtsak "sudo killall tdmtsak" stops the cpu consumption completely. Updated screenshot:

http://www.3111skyline.com/dl/dt/trinity/ss/tsak-96-cpu.jpg

tsak does not run outside of TDM and therefore won't run when X is started from the command line with startx.

Regarding trying to kill tsak, tsak and TDM do not perform any housekeeping. The pipe/socket files created by tsak remain in /tmp. The next reboot or X server restart tsak ignores the tdmrc setting, uses the existing pipe/socket files, and just keeps running, even when explicitly disabled in tdmrc.

I will amend bug report 906 to address these issues.

BTW, killing tsak probably should not succeed because the goal is to ensure nobody can spoof the login screen. I am not surprised that tsak resurrects itself after killing.

I have made some progress on the tsak bugs in GIT hash 3f90a9b; can you please recompile tdebase from GIT and see if this bug still exists?

Thanks!

I have made some progress on the tsak bugs in GIT hash 3f90a9b; can you please recompile tdebase from GIT and see if this bug still exists?

Thanks!

Cleanup of tsak FIFOs when tsak becomes unusable (e.g. keyboard removed) after it was successfully initialized at least once has been committed in GIT hash 632eda3/

Failure to clean up FIFO file when tsak disabled fixed in GIT hash a63606b.

If I correctly understand the two patches, we should be testing the following:

* That Ctrl-Alt-Del works with both UseSAK=false/UseSAK=true

* That pipe/socket files are purged/ignored correctly:
  1) during a reboot/halt (when TDM terminates)
  2) X server restart (which TDM allows)
  3) when a user disables tsak in KControl (tdmrc:UseSAK=false)

* Watch for high CPU usage

A note about a related bug mentioned in bug report 906 comments:

Ownership of /tmp/tdesocket-global is assigned to the system's primary login account. Ownership of that directory is determined by the account UID listed in the tdmrc MinShowUID key and then that account number is grabbed from /etc/passwd.

Also related are bug reports 884 and 925.

Not trying to "pile on." :) Just noting there are several related bug reports, each a little different, each a little similar. :)

> Not trying to "pile on." :) Just noting there are several related bug reports,
> each a little different, each a little similar. :)

No problem!  We need all the tsak bugs resolved soon and I am trying to fix as many as I can.

What would help of course is to have either a master list of issues, or to have separate bug reports for each problem.  Right now we seem to have multiple intertwined issues in each bug report, which is not easy for a developer to untangle. ;-)

That being said, can you (or someone else for that matter) who has experienced problems with tsak compile from the latest GIT sources and see how many issues have already been resolved (and which ones still remain)?  The sooner we can start unsnarling these four related reports the faster the remaining problems can be prioritized and hopefully resolved.

Thanks!

Actually, I started to collate such a list. :) I will post soon.

I just now started rebuilding my package set. To test properly I prefer to reboot to my alternate set of Trinity partitions. I don't like testing these specific types of issues in a VM because VMs are not good for testing hardware related issues. Will be a couple of hours before I can report. :)

Thanks!

(Odpověď na komentář #6)
> I have made some progress on the tsak bugs in GIT hash 3f90a9b; can you please
> recompile tdebase from GIT and see if this bug still exists?
> 
> Thanks!

I tested commit 3f90a9b8 x PS2 keyboard and after NumLock / CapsLock she is still alive! Good news, thank you.

tsak housekeeping implemented in GIT hash 6cfb160.

(In reply to comment #13)
> tsak housekeeping implemented in GIT hash 6cfb160.

What should I test?

With uinput not loaded I see a text message inside the group box. When I load uinput then the message disappears?

Anything else to test?

(In reply to comment #14)
> (In reply to comment #13)
> > tsak housekeeping implemented in GIT hash 6cfb160.
> 
> What should I test?
> 
> With uinput not loaded I see a text message inside the group box. When I load
> uinput then the message disappears?
> 
> Anything else to test?

tsak now cleans up after itself, so you should see the pipe and lock files when tsak is active, and not see them when tsak has been deactivated.

Also, is the text message clear enough?  If not feel free to edit it. :-)

Ok. First test was in a VM. I'll test next in real hardware.

No gripes about the KControl warning string. Very nice that the check box is disabled too.

One note: in my recent updating of the TDM help book, I wrote udev and uinput. In the KControl warning message you have evdev. I presume the latter is more technically correct. To be consistent, I presume I should update the help book to evdev?

evdev is more precise as far as I can tell: http://en.wikipedia.org/wiki/Evdev

I'll update the help file. Easy.

Check the mail list for my latest report of GIT hash 6cfb160.

As I have not been able to reproduce this bug on latest GIT sources, and no one has provided feedback to the contrary, I am closing this bug RESOLVED FIXED.

As always, if this bug reappears on latest GIT sources, please reopen this report!