Samba 4 - zasek v neprerusitelnem cekani

[Dan Lukes]

On 09/22/14 15:50, Miroslav Prýmek:
> na FreeBSD 10.0-RELEASE-p7 mam zasadni problem - jednou za cas (zhruba
> za tyden) zustane proces smbd
> (fileserver samby) trcet v "D" stavu:
>
> # ps aux | grep smbd
> [...]
> [...uzivatel...] 35343   0.0  1.2 563924  99856  -  D    Fri05AM 1:20.98
> /usr/local/sbin/smbd -D --option=server role check:inhibit
> [...]
>
> Prusvih je, ze ten uzivatel se pak nemuze na Windows prihlasit a proces
> samozrejme nejde sestrelit,
> jedine restartovat server, coz je desivej prusvih. Navic korunovanej
> tim, ze se server odmitne restartovat

Pokud proces nelze zlikvidovat ani signalem 9 pak to znaci jedine - 
proces je prave "v kernelu" - tedy zahajeny a jeste nedokonceny syscall.

A to, ze server nelze ani restartovat to jen potvrzuje, zpresnene o to, 
ze zrejme jde o nejaky zamkovy dead-lock, mene pravdepodobne jiny 
problem souvisejici se zamkovanim.

>    PID    TID COMM             TDNAME           KSTACK
> 35343 100509 smbd             -                mi_switch sleepq_wait
> _sx_slock_hard namei vn_open_cred zfs_getextattr VOP_GETEXTATTR_APV
> extattr_get_vp sys_extattr_get_file amd64_syscall Xfast_syscall
> 35343 100738 smbd             -                mi_switch sleepq_wait
> sleeplk __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock
> knlist_remove_kq filt_vfsdetach knote_fdclose closefp amd64_syscall
> Xfast_syscall
>
> Tak nejak z toho teda matne tusim, ze oba thready procesu trci v nejakem
> neprerusitelnem cekani (sleepq_wait), jeden se snazil ziskat atributy
> souboru,  druhy smazat nejake knotes. To mi ale nic nerika ani nepomuze...

Prvni se skutecne snazi ziskat extended atributy souboru, ten druhy 
docela obycejne zavira file-descriptor. Jako projev cisteho hadani si 
dovolim vyslovit domenku, ze oboji se tyka tehoz souboru nebo alespon 
adresare.

> Takze prosim jestli mate jakykoli rady, jak postupovat, poradte prosim,
> je to desnej prusvih...

Problem je race-condition. Dve operace, ktere nastanou v nevhodne casove 
koincidenci. Tedy problem, ktry bud enastavat nahodne, statisticky, a 
patrne nebude spolehlive/snadno deterministicky vyvolatelny.

Coz zasadne komplikuje analyzu problemu i hledani reseni.

> Potrebuju vedet hlavne:
> 1. jestli tuhle chybu muze nejak vyvolat samotnej proces (jako ze by to
> byla chyba procesu, ne kernelu) - to predpokladam, ze ne.

Chyba je v kernelu, vyvolana je konkretnimi pozadavky aplikace, vcetne 
jejich vzajemneho casoveho prubehu.

> 2. jak zjistit nejake dalsi informace o tom, co se deje? (muzu jeste
> neco zkouset behem dneska, zitra rano uz ten server
> musim restartovat, aby se uzivatele mohli prihlasit...)

V tehle chvili muzes vyvolat panic (halt -d) a ziskat dump (pokud mas 
dostatecne velky swap a dump nakonfigurovany pomoci dumpon). Jenze 
vyslednej dump je skoro k nicemu pokud nemas kernel prelozeny s 
debugovacimi informacemi - a i pak je analyza tohohle typu problemu 
extremne obtizna, protoze problem nevznika "v jednom miste", ale 
konkretnim procesem pruchodu dvou soucasne bezicich vlaken kernelu.

Musim rict, ze me by se do toho vubec nechtelo, protoze pres znacnou 
pracnost je uspech dost nejisty ...

Aby byla vubec sance, chtelo by to kernel prelozeny s
options INVARIANT_SUPPORT
options INVARIANTS
options WITNESS_SUPPORT
options WITNESS
makeoptions    DEBUG=-g

viz
https://www.freebsd.org/doc/en/articles/geom-class/prelim.html

To ale znamena znacnou ztratu vykonu.

> 3. je nejaka alespon sebemensi sance, jak tehle situaci predejit? (vim,
> ze informaci je malo, ale aspon neco zkusit...)

No, kdyby nedochazelo k te casove kolizi dvou procesu, zrejme by nedoslo 
k pozoprovanemu problemu. Akorat me trochu utekl vyvoj v tehle oblasti a 
tak vlastne nevim jestli jde paralernimu vstupu procesu do jadra 
zabranit. Zrejem by k nemu nedochazelo, kdyby kernel nebyl MP. Ale 
netusim jestli takhle desitku jest eprelozit lze. Taky by k tomu, 
zrejme, nedoslo, kdyby se vsem syscallum odebral priznak MP_SAFE - pak 
by k paralernimu vstupu do jadra taky nedochazelo.

Mozna by stacilo i jen zakazat vsechny procesorovy jadra az na BS. Al 
eani u toho nevim jak se to udela, ani jestli by to skutecne 
paralelismus zlikvidovalo.

A cenou by samozrejme byla ztrata vykonu.

> 4. je nejaka sance, jak t situaci resit? (asi nejspis zjistit, na co
> proces ceka a nejak to nasilne ukoncit) - to je asi sci-fi, ale lina
> huba...

Proces "v jadre" nelze zadnym zpusobem ukoncit. Takze jedine zabranit 
soucasnemu vstupu, jak vyse zmineno.

Nebo zkusit takovou modifikaci systemu, ktera pozmeni nekterou ze 
zucastnenych vetvi. Zavirani filedescriptoru se asi zbavit nepodari, ale 
pokud se dokazes zbavit ZFS a pouzit UFS, tak dojde ke zmene v druhe 
vetsi a je mozne, ze se tim problem vyresi.

A pak samozrejem navrat k te konfiguraci, kdy to to jeste naposled 
fungovalo - to te ale urcite napadlo taky ...

Dan