This turned into an interesting adventure. In the process I discovered some things about tsak. I wanted to tinker with TDM to see whether I could replicate the runaway CPU hogging reported by others when tsak is enabled. I never could, but that is not the core of this story. After enabling tsak, I was greeted with a dialog to press Ctrl-Alt-Delete to login. Pressing Ctrl-Alt-Delete did nothing. No response. I was left staring at a dialog that would not let me do anything. I had to toggle to a different console and kill the tdmsak process. Then I had access to TDM. For systems that are preconfigured with no alternate console, users would be left with the choice of pressing the reset button or trying to SSH into the box. If there is no boot loader option to boot into the console, then users would be up the proverbial creek with no paddles. I suspect the problem is a conflict for the use of Ctrl-Alt-Delete. TDM uses that keyboard shortcut too. I don't see anything in KControl that allows changing the keyboard shortcut for tsak. I don't see anything that allows changing Ctrl-Alt-Delete in TDM. Looking at the sources, both shortcuts seem hard-coded. After enabling I could not disable tsak. Clearing the check box in KControl had no effect. Rebooting had no effect. From that point on I was greeted with the dialog to press Ctrl-Alt-Delete. After disabling tsak in KControl and rebooting, I compared the tdmrc to a backup copy. No difference. I had no idea what was causing the tdmsak process to insist upon running when explicitly disabled in tdmrc. Investigating further, I noticed many temp files in /tmp, most of which use a numerical directory name, but in particular, a directory named tdesocket-global, of which were files related to TDM and tsak. Pipe and socket type files. Deleting all of those pipe and socket files solved the problem of tsak acting like a possessed d(a)emon. I did not need to reboot. Just delete the pipe and socket files and with the next X-Server reset from TDM, tsak stopped running. Looks to me like tsak is keying first off of those existing pipe/socket files and ignores tdmrc when those pipe/socket files are found. tsak also does not perform any housekeeping during a reboot/shutdown. That is, those pipe/socket files never get deleted. I noticed the /tmp/tdesocket-global directory is assigned ownership of my primary login account. Eventually I figured out that ownership is determined by the account UID listed in the tdmrc MinShowUID key and then that account number is grabbed from /etc/passwd. Curiously, although that directory is assigned ownership to my primary user ID, that user is not allowed to view the contents of /tmp/tdesocket-global. That makes sense in a way because the directory is created by tsak, but ownership should be root:root. I suspect tsak is merely grabbing that information from TDM rather than parsing tdmrc directly. I mentioned numerical directory names. These are created by TDM and are profile directories. TDM performs no housekeeping. Actually the opposite. Every time a user logs in/out and returns to TDM, TDM creates one of these numerical profile directories in /tmp. Without any housekeeping these profile directories accumulate into a lot of wasted space. KDM in KDE3 does not create these profile directories. Questions: Could the runaway CPU usage be related to an accumulation of these temporary files? Possibly after a few hundred have collected the runaway process starts? Could some tsak related problems disappear with simple housekeeping --- flush those temporary files with every reboot/shutdown and start tsak only through the UseSAK key in tdmrc and nothing else? Is there a way to change the keyboard shortcuts for TDM and tsak? If not then why not? Why is tsak assigning ownership based upon MinShowUID from tdmrc? Should ownership of /tmp/tdesocket-global be assigned to root:root? What is the purpose for TDM creating these profile directories? They were not needed in KDE3. Darrell

Dne pá 30. března 2012 Slávek Banko napsal(a): Now I read your second mail and I see - for you was not enough to restart. In Debian this is sufficient, because after reboot the system automatically clean /tmp and /var/tmp. Slávek --

Oops, looks like our messages crossed paths too quick! :) Yes, I have a "cleanup" script in my Slackware system. After my experience yesterday I added some snippets in that script to perform this newly required housekeeping. Yet I think this type of effort indicates a flaw with tsak presumptions. I don't think we should presume that systems perform automatic housekeeping chores. As tsak runs only when using TDM, TDM should perform that cleanup on a reboot/halt request. The fact that a reboot does not stop tsak is evidence that this housekeeping is necessary. Most people will disable tsak from within KControl. When they do that they expect tsak to disappear on the next reboot or X server restart. When a user disables tsak from within KControl, those pipe/socket files should be flushed immediately right then and there. tsak is a good idea but we have a few bugs to quash. :) As I mentioned in my previous message, I did not notice any runaway CPU hogging. I tested in both a virtual and physical machine. I would test further but can't use tsak at all because of the Ctrl-Alt-Delete conflict with TDM. Darrell

On Friday 30 of March 2012 18:06:48 Darrell Anderson wrote: Please, someone is working on repairs SAK? Slávek --