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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
