KDE on Scientific Linux 6.9 logs out one account before login is complete. That is, after supplying the user ID and password, the login screen briefly disappears, the monitor is heard changing its resolution as if it's about to display the desktop, and then the login screen reappears. For the same account, gnome logs in. Both gnome and KDE log in for all other accounts. Just before it failed to log in, I had been using that account, therefrom logged in as root using "su", to run "yum -y update". Upon rebooting, that account could not log in. Newly-installed kernel is -2.6.32-696.16.1.el6.i686. There are some cryptic messages in /var/log/gdm/:0-greeter.log

GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Failed to connect to socket /tmp/dbus-acOeSLN9l9: Connection refused)

The system hadn't crashed.

Any suggestions, or ideas where to look for more clues, are welcome.

Boy, what a pile of <expletive deleted> that sounds like.

Something caused this, I would imagine. Some update, some fiddling with files. Search for that first. To me it sounds like the shell crashed. You could check that by running bash in your shell (bash within bash) and starting up :P.
If /tmp/dbus-acOeSLN9l9 exists, I would delete or rename it. Go through /var/log/Xorg.0.log,l and if you don't find something obvious go through the checks mentioned in your GConf error. Then restart as a different user. If necessary, add one. You can delete him after. Then start X as your offending user this way

yes, check log files, most probably .xsession-errors and/or Xorg.0.log. I would say the login process itself failed, that means an incorrect initialization script (and looks like it is not only user but kde specific too).

If this is affecting only one account out of several, I would consider the most likely culprit to be a corrupt of misconfigured configuration (dot-[filename]) file in that user's /home directory.

One way to test this would be to back up the configuration files in user's home to a separate directory (which could still be within /home), then delete the original files, and test a login; new configuration files will be created on login.

If the login is successful, that would confirm the above theory. To identify which file is borked, you could move them back into /home one by one until the login fails, or you could just say, "the heck with it," and plow ahead.

If Gnome logs in, then surely it has to be one of KDE's user configuration files. Either the file is corrupt, or its permission has somehow been changed. I had this problem once myself. I'd make sure the permissions are OK and if they are, just follow Frank's advice.

Frank's advice was useful. The culprit file was .kde/share/config/kwinrc. After re-setting my title-bar behaviors and window button behaviors to previous values, I compared the saved one to the re-created one. There are still large and significant differences. For example, no [plugins] section in the new file. Does anybody care to see both files?

Glad I could help. I for one don't know enough about that rc file to be much help at parsing it.

Maybe you could use meld or diff to isolate the differences between the two (meld is a GUI version of diff).