Zaledwie piętnaście minut temu pracowałem nad artykułem dla Linux.com, kiedy myślałem, że stracę mnóstwo pracy. Mój ostatni akapit pisałem na temat artykułu zawierającego ponad 1600 słów (wpisując artykuł do systemu internetowego). Wracałem do OpenOffice, aby skopiować i wkleić całą moją pracę przed przesłaniem artykułu, gdy OpenOffice zablokował mój pulpit. Po tym, jak jakieś wyjaśnienie wymknęło mi się z ust, spokojnie przystąpiłem do próby odzyskania pracy. Udało mi się, ale tylko za pomocą wirtualnej konsoli.
Teraz zwykle często oszczędzam, aby uniknąć takich problemów. Ale w tej chwili nie ma funkcji Zapisz wersję roboczą, więc polegam na częstym zapisywaniu w OpenOffice. Zawsze działa i rzadko mam problemy. Tym razem jednak to zrobiłem. Kiedy nie ikonizowałem OpenOffice (używam Elive-Compiz, więc aplikacje minimalizują do ikon) wszystko oprócz kursora i klawiatury zamarło. Tak mi się przynajmniej zdawało. W rzeczywistości OpenOffice spowodowało problem uniemożliwiający mi dostęp do dowolnej aplikacji. Mogłem przesunąć kursor, ale to było to. Nie mogłem uzyskać menu ani wchodzić w interakcje z żadnymi aplikacjami.
Co się stało?
Dla tych, którzy są ciekawi tutaj, jest wyjście mojego Błędy ~ / .xsession plik:
zarządzane okno: 0xc0155b: 0x40abdc, 402
zarządzane okno: 0xc01576: 0x40afed, 402
Nieobsługiwana właściwość: 41 czcionek
Nieobsługiwana właściwość: 41 czcionek
_e_container_cb_mouse_down
_e_container_cb_mouse_down
_e_container_cb_mouse_down
zarządzane okno: 0xc015dc: 0x14035fe, 402
akt fn max
maksymalna analiza: BRAK
zarządzane okno: 0xc01637: 0x1c0b86d, 402
_e_container_cb_mouse_down
Błąd efreet_desktop_new: brak sekcji Wpis na pulpicie
_e_container_cb_mouse_down
zarządzane okno: 0xc016f0: 0x240000a, 402
Po kilku badaniach wydaje się, że może to być błąd autoraise. To oczywiście nie wspomina, jak udało mi się wyjść z tej sytuacji. Spójrzmy.
Jak to wyszło?
Na szczęście miałem dobry pomysł, która aplikacja spowodowała problem. Założyłem to, ponieważ OpenOffice Writer był ostatnią aplikacją, z którą miałem do czynienia. Nawet jeśli nie był to OpenOffice, miałem następujące aplikacje otwarte, które mogły spowodować problem.
- Claws Mail
- Firefox
- Rhythmbox
- GnuCash
- xterm
Musiałem mieć nadzieję, że problemem nie był Firefox, ponieważ takie dane naprawdę potrzebowałem, aby zapisać. Z moją listą w ręku przeskoczyłem do wirtualnej konsoli, aby sprawdzić, czy mogę mieć szczęście.
Dostanie się do wirtualnej konsoli
Konsole wirtualne umożliwiają skuteczne zalogowanie więcej niż jednego użytkownika. Możesz też zalogować się do tego samego użytkownika, przy czym jedno wystąpienie jest pulpitem graficznym, a drugie — pulpitem wiersza polecenia. Aby dostać się do różnych wirtualnych pulpitów, wprowadź klawisze Ctrl-Alt-F * (gdzie * to 1-0). Kiedy dotarłem do wirtualnej konsoli, zalogowałem się przy użyciu moich standardowych informacji o użytkowniku i zostałem powitany poleceniem bash. Ponieważ uznałem, że winowajcą był pisarz OpenOffice, chciałem uzyskać PID tej aplikacji, więc wydałem polecenie:
ps aux | grep soffice
Co dało właściwy PID dla aktualnie uruchomionego polecenia soffice -writer. Następnym krokiem było wydanie komendy kill na PID w następujący sposób:
zabij PID
Gdzie PID to rzeczywisty PID podany mi przez polecenie ps powyżej.
Kiedy proces został zabity, wskoczyłem z powrotem na moją oryginalną konsolę (w moim przypadku była to Ctrl-Alt-F7) i oto odzyskałem kontrolę nad komputerem. Mógłbym wtedy ponownie otworzyć OpenOffice, zapisać swoją pracę, dokończyć artykuł i przesłać.
Bullet Doged.
Końcowe przemyślenia
Tak, tej całej sytuacji można było uniknąć dzięki działającej funkcji Zapisz wersję roboczą, ale nie jest ona jeszcze dostępna. Mógłbym również użyć innego pulpitu. „What ifs” może trwać i trwać. Ale ostatecznie takie rzeczy się zdarzają i zawsze miło jest wiedzieć, że masz środki, aby rozwiązać problem, nawet jeśli musisz być kreatywny, aby to zrobić.
