Dotaz: Občasne zaseknutie grafického prostredia

[ewew]

Přílohy:

• pad grafickeho prostredia (1676 bytů)
• xorg.backtrace.logfile (2628 bytů)

Zdravím

Počas používania operačného systému Debian Squeeze občas dochádza k zamrznutiu grafického prostredia gdm3. Nie je možné použiť klavesnicu na zmenu na tty1,klinúť ale je možné pohybovať kurzorom. Jedina vec čo je možná je použiť tieto klávesové skratky ALT+SysRq+s (sync),ALT+SysRq+u (remount ro),ALT+SysRq+b (reboot). Chcem zistiť či je to len mojím systémom alebo je to bug v X servery.

Príloha z súborov Xorg.0.log a ešte jeden ale neviem už presne z ktorej skupiny je.

Ďakujem

---

---

Odpovědi

[pepe_]

A ALT+SysRq+K ti nejde ?

[Matlák]

Mno, to mu možná půjde, ovšem ono to jaksi nesmaže framebuffer ani nepřepne GPU do textového režimu, čili je nutné "poslepu" se z tty přihlásit a nahodit Xka znovu.

Mám s tímhle bohaté zkušenosti, jelikož používám k přepínání klávesových rozložení setxkbmap, který je po nějakém čase (řádově desítky hodin) nepřetržitého provozu X serveru schopný tento dostat do tazatelem popisovaného stavu. Vtipné je že když se taková nereagující, napohled zamrzlá Xka s hýbajícím se kurzorem nechají půl hodinky být, samy nakonec "odmrznou" chyba je mizerně dokumentovaná, dá se k ní najít jen pár bugreportů - ovšem uživatelů kteří s tím mají problém je málo (už jen proto jak málo je uživatelů spouštějících 100x za instanci X program setxkbmap) a tak není ani jeden z těch reportů vyřešený... a asi ještě dlouho nebude

[ewew]

Spomínanú skratku som neskúšal.

Je v tom nejaký rozdiel ? V /proc/sys/kernel/sysrq mám hodnotu 438.

Mňa zaujíma či existuje nejaké opatrenie aby X server neskončil v slučke, píše to v súbore Xorg.log.

Tiež so uvažoval o použitý kvôt alebo cgroups. Zaujimálo by ma prečo nezakročil OOM-killer, ale asi to nezväčšilo obsadenie pamäte natoľko aby bol dostatočný počet bodov na oom-kill.

Inak po použitý spominaných sysrq skratiek som zatiaľ nemal žiadne fsck recovery.Myslím, že tento postup aspoň niečo z dát pošle z bufferu na disk.

Druhý súbor s názvom pád grafického prostredia bola príčina gnome-session. Tento program z nejakého dôvodu skončil s chybou 11. Daná udalosť sa prejavila reštartom grafického prostredia. Vyzeralo to tak ako keby som sa odhlásil.

[Matlák]

Myslím, že tento postup aspoň niečo z dát pošle z bufferu na disk.

Ano pošle, a to proto že zbytek systému mimo X normálně běží. Zkuste se přihlásit přes SSH k té mašině jinak obecné opatření proti zacyklení X serveru neexistuje, viz můj post (dosud nevyřešené, i když pravděpodobně řešitelné (jsem líný procházet zdrojáky)). Musí to být spojené s nějakou akcí před tím než se Xka zacyklí, popřípadě s nějakým nastavením - zkuste vypnout efekty, popřepínat grafické ovladače, zkoušet různé programy atd atp..

[ewew]

SSH nie je schodná cesta pretože tento server nepotrebujem. Ja tento počítač používam ako osobný nie ako server. Možno je to zvláštne mať debian na osobnom PC, ale mne vyhovuje. Ubuntu je príliš náročné na výkon a ja nepotrebujem všeliake ozdoby na ploche. Načo by som svoj starý P4 2 GHz celeron s 768 MB RAM a grafikou Geforce FX5200 128 MB trápil náročnou grafikou

V podstate sa na tom učim ako spravovať debian, zabezpečiť a prípadne vymyslieť lepšie riešenie problému

Rozmýšlam, že naištalujem PAM modul pre cgroup alebo použijem pam_limits.so.

[l4m4]

Jaký je problém se ssh na osobním počítači? Na všech osobních počítačích mi běží sshd, protže jsou osobní a osobně se na ně chci zdálky přihlásit...

[ewew]

Problém nie je žiadny. Len vzdialené prihlásenie zatiaľ nepotrebujem. V režime standalone by väčšinu času čakal na spojenie, možno cez inetd alebo xinetd by som to mohol dať.

[pepe_]

Plácnutí do tmy :  Co udělat script kterej bude monitorovat myš a když zmáčkneš  levé+prostřední(kolečko)+pravé tlačítko ,  dá  service gdm stop ; service gdm start

[ewew]

Myslím, že sprístupňovať si myš skriptu nie je dobrý nápad. Zariadenie ktoré obsluhuje myš má práva 700 a vlastník a skupina je root:root. Dal som cat na dané zariadenie a výstup bol nevhodný na použitie v skripte. Pravdepodobne by nestačila veľkosť premennej do ktorej by bol dany obsah ukladaní. Nebolo by od veci takúto funkciu vložiť do sysrq. V manuále je zmienka o takejto možnosti.

Asi bude lepšie poslať tie backtrace vyvojarom debianu.

Možno je to extrémný prípad ale čo keď by X server na nejakom dôležitom servery spôsobil nedostupnosť služby vďaka tomu, že X server vyťaží CPU na 100%. Viem, že grafické na server nepatrí, ale poukazujem na to, že v dnešnej dobe je nutné mať ošetrené takéto veci pre iné typy služieb. Pochybujem, že je možné sa dostať cez sshd keď je celý server na 100% vyťažení vplyvom danej chyby a napraviť danú situaciu.

[Matlák]

X server na nejakom dôležitom servery spôsobil nedostupnosť služby

To nehrozí, prostě proto že dnešní servery mají většinou víc jak dvě jádra a Xka si seberou jen jedno jinak samozřejmě platí že X na server nepatří, neznám ani nikoho kdo by potřeboval na serveru mít jakékoli X aplikace (a chtěl je používat přes X forwarding, natož aby chtěl z jakéhokoli důvodu spouštět X přímo na serveru).

Co se té myši týče, myslím že není risk v tom zpřístupnit ji ke čtení... i když ke zpracování dat by bylo asi lepší napsat nějaký démon - na druhou stranu, k čemu by to bylo? Sestřelit X už tak jde přes Sysrq+K, ten program by beztak nemohl dělat nic jiného (beznadějně jsem si u zatuhlého X serveru připadal i po přihlášení na ten stroj zvnějšku )

[michich]

Máme přece preemptivní multitasking. To, že nějaký proces chce 100% CPU, neznamená, že jiné procesy mají smůlu.

[michich]

Bug v driveru nouveau.

[ewew]

Ak je to bug, tak by možno nebolo na škodu pozbierať od viacerych úžívateľov backtrace z X servera potom to odoslať vyvojarom X servera a vyvojarom Debianu.

[michich]

Vypadá to jako tento bug: http://bugs.debian.org/628420

[ewew]

Aký postup navrhuješ ?

Mnou spomínané opatrenia by mohli pomôcť alebo to s tým nesúvisí ?

[Matlák]

Máš to tam napsaný.. upgrade kernelu, popřípadě změna grafického ovladače..

[pepe_]

A zase ten noveau , to už je prealfa ne podle chování jako BSOD ?

[ewew]

Mám čerstvé informácie pred pár minutami došlo k zamrznutiu grafického prostredia. Použil som ALT + SysRq + K. Došlo k odblokovaniua a pritom došlo k reštartu gdm3, ekvivalent sh /etc/init.d/gdm3 restart alebo init 1 . Pritom sa ozval aj hardvérový zvuk, to značí, že alsa pritom skolabovala. Náprava sh /etc/init.d/alsa-utils restart a potom reset . Vtedy sa ozvalo lupnutie z výstupu zvukovej karty. Login prebehol korektne.

Možno keby použijem trojkombináciu ALT + SysRq + S; ALT + SysRq + U ; ALT + SysRq + (B alebo K) , možno by som mal nejaké výstupy.

Jedine čo som dostal z logov je, že prostriedok nie je k dispozicii. A firefox oznámil, že došlo k resetu spojenia s X serverom :0.0. dmesg napísal pod značkou nouveau,že sa mu nepodarilo dostať kanál 1 do stavu idle.

[ewew]

Daný problém vyriešila zmena ovladača grafiky. Z open-source na proprietarný.

Označujem otázku (dotaz) ako vyriešený.