Just about fifteen minutes ago I was working on an article for Linux.com when I thought I was going to lose a ton of work. I was writing my last paragraph on a 1,600+ word article (entering the article in their web-based system). I was going back to OpenOffice to copy and paste all of my work before submitting the article when OpenOffice locked up my desktop. After an explicative escaped my mouth I calmly set about to try to recover my work. I succeeded, but only with the help of a virtual console.
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.
No comments:
Post a Comment