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