Dotaz: Sarge, Linux-2.6.12.2, gdmflexiserver, xterm v Xnestu nefungují, delší

[©]

Dobrý den,

mám poměrně závažný problém, který nedokáži vyřešit už 2 dny. Zevrubně jej popíši.

Jelikož mám rád monolitická jádra, rozhodl jsem se že si i v Debianu zkompiluji monolitický kernel. Vzal jsem svůj starý a osvědčený konfigurák, který jsem používal ještě na Slackwaru, rozbalil a zkompiloval nový kernel pomocí

make oldconfig
make bzImage
make modules && make modules_install

zkopíroval jádro atd. a nabootoval ho.

Vše na první pohled fungovalo až do chvíle, kdy jsem chtěl zkusit spustit GKrellM. Zadrhnul se, v logách žádné chyby. Řekl jsem si, že to je nějaká blbost a tak jsem si chtěl spustit `gdmflexiserver -n', že se zkusím zalogovat pod jiným uživatelem a spustit GKrellM z jiného účtu. Jenže ouha. GDM Flexible Server se taktéž zadrhnul. To už bylo na pováženou. Zkusil jsem tedy spustit samotný `Xnest :1' a do něj XTerm pomoci DISPLAY=:1 xterm:

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

xterm Xt error: Can't open display: :1

Xnest přitom při každém pokusu o spuštění vypisuje následující:

AUDIT: Mon Jul  4 21:10:11 2005: 4843 Xnest: client 1 rejected from local host

Zkusil jsem tedy `xhost +' a když to nezabralo tak dokonce i `xhost +localhost'. Zase nic. Stále to samé.

Zkusil jsem tedy GKrellM i GDM Flexible Server spustit ve strace.

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(7634), sin_addr=inet_addr("127.0.0.1")}, 16

Na tom se oba zaseknou.

Ze zoufalství jsem rebootoval do starého Debianího jádra 2.6.8-i686 a hle, zde vše funguje jak má. Vzal jsem tedy .config z tohoto Debianího distribučního jádra a zkompiloval s jeho pomocí to nové jádro 2.6.12.2. Ale nepomohlo to.

A teď přijde to nejlepší, když jsem psal tento přízpěvek, tak se mi spustil najednou GKrellM, který jsem zapoměl běžet ve strace. Po 10 minutách. Zjevně to tedy na něčem time-outuje a to je to, co potřebuji zjistit, abych to přenastavil. Co by to mohlo být?

Prosím o jakýkoli nápad, protože čekat 10 minut na to, až se mi spustí aplikace - no, to není zrovna to pravé ořechové, že?

Odpovědi

[©]

Dodatek:

gdmflexiserver -n -d
Sending command: 'VERSION'
  Got response: 'GDM 2.6.0.8'
Sending command: 'AUTH_LOCAL 8f6892c41c74377ffd5f641e1eab883a'
  Got response: 'OK'
Sending command: 'CLOSE'
Sending command: 'VERSION'
  Got response: 'GDM 2.6.0.8'
Sending command: 'AUTH_LOCAL 8f6892c41c74377ffd5f641e1eab883a'
  Got response: 'OK'
Sending command: 'QUERY_VT'
  Got response: 'OK 7'
Sending command: 'CLOSE'
Sending command: 'VERSION'
  Got response: 'GDM 2.6.0.8'
Sending command: 'AUTH_LOCAL 8f6892c41c74377ffd5f641e1eab883a'
  Got response: 'OK'
Sending command: 'CONSOLE_SERVERS'
  Got response: 'OK :0,socrates,7'
Sending command: 'CLOSE'
Sending command: 'VERSION'
  Got response: 'GDM 2.6.0.8'
Sending command: 'FLEXI_XNEST :0 1000 8f6892c41c74377ffd5f641e1eab883a /home/socrates/.Xauthority

Takhle se zasekne ten gkmflexiserver s parametrem pro debug (-d).

[©]

Tak jsem se zas o kus posunul. Zjistil jsem, že aplikace z nějakého záhadného důvodu se snaží používat síťový socket namísto unixového socketu. Ale proč?

[©]

s/přízpěvek/příspěvek/g

[©]

Tak jsem s pokusil hledat i ve zdojácích a podobně. Samosebou bez úspěchu. Nakonec se ukázalo, že to je jen špatně nastaveným firewallem. Díky kluci z #[cenzura]censored[/cenzura].cz.

Poučení pro všechny ostatní: Nejjednodušší myslitelná příčina bývá nejpravděpodobnějším zdrojem problému. Vždy na tuto poučku zapomenu a vždy se mi to nevyplatí. Tentokrát jsem si byl natolik jist svým firewallem, že je nastavení v pořádku, že jsem zbytečně utratil dva krásné večery nad úplnou hovadinou.

[Zdeněk Burda]

Zas taková hovadina to není, když ti firewall funguje v jednom jádře bez chybně a v druhém to dělá takovéhle kraviny. Otázka zní, v kterém jádře to je bez chybné.

[©]

Viz http://www.abclinuxu.cz/forum/show/93158#6

No nevím, vzhledem k tomu, že původcem paketů je samotný kernel... Předpokládal bych tedy spíše chybu v NetFilteru. Ale těžko říci, nejsem z rozhodně povolaný to rozsoudit.

Jestli ste někdo sto kouknout do zdrojáků, co se změnilo a zjistit, zda je to bug či ne, prosím napište to sem a učiňte případný bugreport. Děkuji.

[©]

Samosebou NetFilter je také v jádře, ale na druhou stranu je to dosti osamostatnělý projekt, který ani celý v jádře není (viz jeho patch-o-matic).

[©]

Resume:

# This causes local network socket traffic corruption! Why?
# $IPTABLES -A PREROUTING -t mangle -m state --state invalid -j DROP

V jádře 2.6.8-i686 z Debianu Stable (Sarge) nepůsobí uvedené pravidlo nejmenší problém. Ve vanille 2.6.12.2 působí problém. Otázka zní proč? Doporučujete bug-report? Změna v chování je totiž dosti zásadní. Každopádně by mě to opravdu na první pohled nenapadlo. Možná, že jsem přeci jenom tomu svému firewallu věřit mohl. Taková změna je dost nečekaná (nezkoumal jsem zatím ChangeLog NetFilteru, ale asi to brzy udělám).

[#Tom]

Zajímavé je, že lze zapsat podobně nesmyslná pravidla pro iptables, jako je tohle:

iptables -I INPUT -i lo -j DROP

To se pak v konzoli ani nedostanu do systému. Zní to jistě ujetě, ale podobně můžou účinkovat i jiná pravidla. Než jsem našel chybu ve firewallu, taky jsem se pěkně pobavil :) Od té doby mám

iptables -I INPUT -i lo -j ACCEPT

[Roman]

Heh, diky kluci za info... Diky povoleni loopbacku se mi konecne zacaly spoustet veci z KDE hned a ne az za X minut Nejak jsem to pricital tomu KDE a necekal jsem, ze bota bude ouplne nekde jinde...

Dik Roman

[©]

Tys neměl povolenej loopback? Taky slušná práce!

LOOPBACK=lo+
### ALLOW LOOPBACK TRAFFIC
$IPTABLES -A INPUT  -i $LOOPBACK -j ACCEPT
$IPTABLES -A OUTPUT -o $LOOPBACK -j ACCEPT