XFCE Window Manager Recovery

The XFCE window manager, at least in its Xubuntu incarnation, seems surprisingly fragile. Every now and again, it won’t start up: all the auto-starting application windows pile atop each other on a single workspace, with no title bar or window decorations, with no way to move them around or change focus. In some cases, the mouse will be active and the keyboard will be dead. This is Not Good.

Rebooting that sucker isn’t productive, as the failure seems to occur most often after a normal system update that, inexplicably, clobbers the window manager’s state information. After that, the window manager will wake up dead every time.

The usual recovery technique involves activating a terminal window and entering xfwm4 --replace to forcibly restart the XFCE window manager, clear the state, and ensure it’s the default. That is remarkably difficult with a nonfunctional keyboard and can’t be accomplished remotely without access to the jammed user’s X session.

What has worked is to SSH in from another PC and delete the XFCE caches for the affected user:

cd ~/.cache
rm -rf xfce4
rm -rf sessions

You can blow away the entire .cache subdirectory if you prefer.

That this should not be necessary goes without saying. Remember that XFCE is currently the least-awful Linux Desktop Environment; all the rest have even greater complexity and much larger problems.

16 thoughts on “XFCE Window Manager Recovery

  1. can’t be accomplished remotely

    why not? –display :0.0 should do it…

    1. I think that means I must configure the deader to run with X listening for incoming connections before its window manager goes toes-up, using xhost to give my box access over the network. I’ll definitely need some dry runs to get that right.

      Fortunately, everything sits behind a hardware firewall, so the usual don’t-let-X-listen-to-TCP security issues aren’t relevant. I think I must rejuvenate the laptop for this project, because I have all the others set up with SSH using public keys on an unusual port. [mmmph]

      1. Shouldn’t. :0.0, rather than localhost:0.0, will run over a named pipe, not tcpip.

        You might need nohup ro survive ssh hangup.

        1. (just to be clear you need to run this on the box with dead x, in an ssh/whatever session connected from somehwere else, not on another box. –display :0.0 forces any x command to the local display regardless of where it might default fwd to.)

    1. that would start the window manager on the machine you’re connecting *from*, which is not the desired outcome. :0.0 will force it to the local screen on the machine you’re connected to.

  2. Hi, I’m using Debian and XFCE and never had this Problem… but on my second Laptop there is Xubuntu installed… an it has exact that problem… I’ll try your solution.
    Til now I always started ” xfwm4″ and I got my TitleBars back

    Seems as Xubuntu has a Problem….

    1. Til now I always started ” xfwm4″ and I got my TitleBars back

      Now try that without tapping on the keyboard… [grin]

  3. Yikes! What part of this was developed at Miskatonic University? My older Linux boxes never had ready access to the outside world. (Local network only) Once I had a working setup I was the only one who could screw it up… The system I’m doing will be in a similar situation once built, without even a phone line (and a almost-a-Faraday cage due to the steel sheathing).

    Dumb question: would it be worth it to have a minimal system (with access to the main files) available at the bootloader? Perhaps an old, stable kernel with a command line or really dumb windowing interface and most services turned off. Analogous to the Windows “Safe Mode”.

    1. a minimal system (with access to the main files) available at the bootloader?

      The “recovery” entry in the Grub menu (hold left-shift during boot if you haven’t already gimmicked it to display every time) gets you to a failsafe graphics startup that uses a bone-stock VESA mode that should always work. You can also use a command-line session without starting X, which can be very handy.

      Of course, for completely crunched systems, you boot System Rescue Disk from a USB stick and go at it from there…

      1. Urrk. That’s what I get for not following Linux developments. My Grub is 0.9 and seems to be ignorant of any failsafe (or any left-shift menu), at least on a quick scan of the info pages. Something about 12 year old software. Stone knives and bearskins, anyone?

        I’ll have to see if the P4 can be persuaded to boot from a USB stick…

        1. My Grub is 0.9

          Yup, it’s time to get with Grub2, which had delightful version numbers around 1.9-ish for quite a while. It hit 2.00 in Ubuntu 12.10; one must always beware double-ought versions…

  4. I might be wrong, of course, but I believe that, depending on which part of the input system get’s blocked, vnc to display 0 might help you with keyboard input. Or Synergy+

    PS. first time commenting here (I think) but have been reading you blog for a long time Ed. I’ve lost count of the things I’ve learned from you. Thank you from Valencia, Spain.

    1. vnc to display 0

      If only I had the foresight to set up VNC beforehand… [sigh]

      I’ll try that, along with the other suggestions, to make sure I understand what’s going on before it fails again. I have the sickening suspicion that a dead window manager means a lot of the fancy remote connection tricks won’t work, but it’d be good to know that’s the cause, rather than a configuration error that’s even harder to troubleshoot with a dead box.

      Thanks for the good words; glad to share what I’ve discovered!

Comments are closed.