ipop3d timeout

[Pavel Kankovsky]

On Tue, 7 Aug 2001, Ing. Pavel PaJaSoft Janousek wrote:

> 	A konfigurace inetd nepomuze? Tam myslim je take parametr pro
> neaktivitu... - jinak s tim procesem - i kdyz kilnete dotycny ipo3d
> proces, nedomnivam se, ze zamek se uvolni - aspon v mem pripade ten
> zamek je drzen kernelem a skutecne uvolnen az po cca 30 minutach (IMHO
> ovlivnitelne nekde hluboce v /proc/...;-)

Blbost. Kernel po smrti procesu zadne jeho zamky nedrzi (za jistou
vyjimkou lze jedine povazovat cislo portu bez SO_REUSEADDR, na kterem
kernel z pochopitelnych duvodu nejakou dobu sedi, nez k temuz portu
pusti nekoho dalsiho).

c-client pouziva dva druhy zamku: dotlocky (schranka.lock) a specialni
zamky (/tmp/.124.456), kterymi si predavaji kontrolu jednotlive programy
nad c-clientem. V prvnim pripade je to tak, ze zamek plati urcitou dobu od
casu posledni zmeny toho dotlockoveho souboru (standardne asi 5 minut, lze
to zmenit v tom tajnem konfiguraku), v druhem pripade zamek plati pouze
v pripade, ze ma nejaky proces dany soubor zamceny pres fcntl(), coz
pochopitelne po smrti procesu okamzite pomine.

Jestli nejaky zamek nekde visi 30 minut, tak je neco opravdu, ale opravdu
spatne.


On Tue, 7 Aug 2001, Miroslav Lednicky wrote:

> K tomu, aby to fungovalo opravdu reverzni zaznam zapotrebi neni.
> Ted to tak provozuji na 2 sitich a chodi to bez timeoutu.

Samozrejme. Staci, aby hledani reverzu rychle zjistilo, ze zadny reverz
neni. Problem nastava vetsinou jen v (bohuzel pomerne caste) situaci, kdy
je reverzni zona nadelegovana na nameserver, ktery nefunguje, nebo se
k te zone nechce znat (jev znamy jako "lame delegation"). Pak totiz klient
nikdy nedostane odpoved, kterou by mohl povazovat za definitivni (at uz 
v pozitivnim nebo negativnim smyslu) a skonci az na timeout.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."