How a virtual console can keep you from losing work
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.
Advertisement
Thinker: You are an Idiot.
10 years of Running Linux I’ve had 3 Crashes.
THREE Crashes in TEN Years
5 years of Running Windows I’ve lost count of how many times its crashed. I do remember a day when it crashed over 20 times in one day.
this won’t always work. I mean, you may have to log as root and do a kill -9, depends on which app you have to kill.
I’m still wondering WHY I have lost 2 minutes of my life reading a post about $~ kill PID in TWO THOUSAND AND NINE…
MKR: You are correct. The version I needed was within Firefox. And yes, when I restarted OO it recovered what what I had last saved. And yes, you are correct about not needing the Ctrl key to return…it’s just habit for me. ;-)
OO does recover documents, but the article clearly indicates that the version in Firefox was more important.
I’m sure when Mr. Wallen opened OO back up, he was pleased to see its document recovery window. I think the point of this article was not for these particular applications, but to provide a general guide to killing an application when it causes the windowed environment to seize up.
Also, you don’t need the control key when you’re out in console land. The control key just tells the desktop environment to let go of the screen.
I have two thoughts after reading this article:
1. There is no such thing, that Linux is more stable than Windows. Maybe in 1998 it was true.
2. Instead of using OpenOffice I would suggest use of Microsoft Office. I don’t remember when, but it was long time ago when MS introduced document recovery after crash. And this is only one of hundreds advantages over OO.