Logging out from xfce fails and hangs the window manager under the following circumstances - using a newly created user and the default panel configuration:

Log out using the "application menu" icon (bottom of dropdown menu). Log back in, then logout again the same way. After a couple of tries, the session manager hangs and the desktop is never cleared. After a lengthy timeout, the login screen reappears, and upon logging in, xfwm4 does not start/stay up (can't tell which). The desktop appears, but with no window manager it is pretty unusable! Have to delete and recreate the home/<user> directory to get back to working WM!

Same problem occurs if xfce-action-buttons is shifted to session-view and all the buttons except logout are unchecked (to conserve panel real estate. It MAY occur even if all the buttons are left in their default state - not sure.

The only reliable way to logout seems to be to leave xfce-action-buttons in its default (dropdown menu) state and use the "logout" on the action-button dropdown.

Whoops!

Update to previous post. The bug is unrelated to the xfce-action-buttons state. It may relate to the time it took me to play with the properties. The following is the simplest failure mode:

Create new user directory (while in runlevel 3). Switch to runlevel 4 and logon. Select the default configuration. Logoff using the "application menu" dropdown. Immediately log back in. Logoff again. Repeat logon-logoff one more time. That last logoff takes a LONG time (maybe a minute or 2) to get back to a logon screen. Logon again and there will be no window manager.

Since I was able (in a real account) to actually logon and logoff without problems, but each session was fairly long, and I didn't immediately try to log back on, my guess is that one of the session/window manager programs is getting hung up and eventually something times out, leaving the user's session files in an unhappy state that breaks xfwm4.

My hardware is 'uname -m -p'

i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux

I'm running vmlinuz-generic-smp-3.2.29-smp and xfce-4.10.0 (using a clean install in another disk partition)
when the problem occurs. xfce-4.6.2 (on slackware-13.37-stable) works just fine

If the problem persists try adding your user account to the "wheel" group.

Further update - the corrupted file (after the LONG logout) is /home/<user>/.cache/sessions/xfce4-session-<hostname>:0
It does not contain Client lines for xfwm2, which explains why the next logon doesn't have a window manager.
If one looks at the session directory right after the long logout, there is an xfce4-session-<hostname>:0.bak file
which IS complete. Replacing the broken session file with the backup fixes the problem (until the next time the logout
hangs up). I'm going to try unchecking the box in logout that saves a new session file to see if that stops the problem, at least until somebody fixes it.

I have no idea what is hanging up the logout and causing the corrupted session file to be written. It doesn't fail every time, but often enough to be a real problem.

I had a similar problem, it also affected my taskbar not being able to save settings. Here's what I did to fix it:
I made sure that "logout saves session" was checked, then I logged out and went into a virtual terminal (ctrl-f6), then I deleted everything in ~/.cache/sessions/, and restarted computer. Logged back in and I didn't noticed any problems after that, so far.

1 members found this post helpful.

Thank you, that corrected a whole host of visual errors on login (rainlendar2 layout) and system performance sluggishness (logout, restart)
Logout is immediate, where it used to be >20'ish seconds.

Mad Props.

With credit here...

All these workarounds are nice, but do not address the original issue - why does logout hang up, leaving a corrupted session file? I was kind of hoping that someone who understood the session management process better than I do might comment and help resolve the underlying issue. Unchecking the option to write a new session file upon logout seems to prevent the creation of new corrupted session files, but the check box exists for a reason, which this "fix" defeats.