Now normally I do frequent saving to avoid such issues. But right now there is no Save Draft function so I rely on frequent saving to OpenOffice. It always works and I rarely have issues. This time, however, I did. When I un-iconified OpenOffice (I am using Elive-Compiz so applications minimize to icons) everything but he cursor and keyboard froze up tight. Or so I thought.What actually happened was that OpenOffice caused an issue keeping me from gaining access to any application. I could move the cursor but that was it. I couldn’t get a menu or interact with any applications.

What happened?

For those that are curious here is the output of my ~/.xsession-errors file:
window managed: 0xc0155b : 0x40abdc, 402
window managed: 0xc01576 : 0x40afed, 402
Unhandled property: 41 font
Unhandled property: 41 font
_e_container_cb_mouse_down
_e_container_cb_mouse_down
_e_container_cb_mouse_down
window managed: 0xc015dc : 0x14035fe, 402
act fn max
max parse: NONE
window managed: 0xc01637 : 0x1c0b86d, 402
_e_container_cb_mouse_down
efreet_desktop_new error: no Desktop Entry section
_e_container_cb_mouse_down
window managed: 0xc016f0 : 0x240000a, 402

After a bit of research it looks like it could be an autoraise error. That, of course, doesn’t mention how I got out of this situation. Let’s take a look.

How it worked out

Fortunately I had a good idea which application caused the problem. I assumed this because OpenOffice Writer was the last application I had any interaction with. Even if it wasn’t OpenOffice I had the following applications open that could have possibly caused the problem.

• Claws Mail
• Firefox
• Rhythmbox
• GnuCash
• xterm

I had to hope that the issue wasn’t Firefox, because that was the data I really needed to save. So, with my list in hand I hopped over to a virtual console to see if I could get lucky.

Getting to a virtual console

Virtual consoles allow you to, effectively, have more than one user logged in. Or you could have the same user logged in with one instance being a graphical desktop and the other a command line desktop. To get to different virtual desktops you enter the Ctrl-Alt-F*keys (Where * is 1-0). When I got to the virtual console I logged in with the my standard user information and was greeted with my bash prompt. Since I assumed the culprit was OpenOffice writer I wanted to get the PID of this application so I issued the command:

ps aux | grep soffice

Which gave the proper PID for the currently running command soffice -writer. The next step was to issue the kill command on the PID like so:

kill PID

Where PID is the actual PID given to me by the ps command above.

When the process was killed I then hopped back to my original console (in my case it was Ctrl-Alt-F7) and, lo and behold, I had regained control of my desktop. I could then re-open OpenOffice, save my work, finish my article, and submit.

Bullet Doged.

Final thoughts

Yes this whole situation could have been avoided with a working Save Draft feature, but that is not available yet. I could have also been using a different desktop. The “what ifs” could go on and on. But ultimately these things happen and it’s always nice to know you have the means to solve the problem, even if you have to get creative to do so.