От известно време насам имах проблеми с IMAP сървъра на машината си. То въобще на тая машина се случваха някакви странни аномалии. Всичко започна с едно неистово забавяне при влизане в мейла през използвания SquirrelMail. Трябваше по-бързо да се сетя, че проблемът не е в него, просто като проверя колко бързо работи самият Courier IMAP. Проблемът беше, че трябваше да понауча това-онова от самия протокол, а и забавянето е нещо относително, когато връзката ти е под всякаква критика.
Започнах да тествам самия IMAP сървър. За целта тръгнах да правя статистика за извикванията на системни функции със strace (опцийката “-c”). Резултатът беше многозначителен, предвид, че забавянето, както изглежда беше с write(), да даже не беше ясно писане къде и от кой от всичките процеси, което сървъра пуска. За щастие ltrace свърши по-добра работа със същите опции - гадната функцийка, която отнемаше на моменти 80% от времето при заявка през SquirrelMail се оказа FAMOpen(). Оказва се, че Courier IMAP зависи от т.нар. File Alteration Monitor при отварянето на файлове (клиентския пакет libfam0c102 и сървърния fam в Дебиан). Сървърната му част от своя страна зависи от RPC Portmapper (пакетът portmap). Проблемът се оказа, че с iptables правило бях орязал връзката до 111-то порт и двете гадинки не можеха да комуникират. Интересно ми е колко още работи за се бозили заради това…
Малък извод: Когато имаш свободен софтуер, който ти позволява да правиш някакъв вид профилиране на процесите (в случая strace и ltrace), достъпна документация за функциите (за да установиш за какво служи FAMOpen()), отворена система (за да направиш връзката с portmap) и съвсем малко (в моя случай) мозък… нещата все има как да се наредят.
Popularity: 8% [?]
Този FAM ми праве??е и на мен проблем, който се изразява??е в това , че спира??е ( и все още не съм разбрал защо ) , тъй като не остава никакви съобщения за гре??ки. Но пък с него има една благинка която може да се окаже много полезна за потребителите, и тя е автоматичното известяване от IMAP server на клиента за пристигнала поща. Тази опция е IDLE, http://www.courier-mta.org/?imapd.html.
Този коментар може да не е полезен по темата, но ако се разбере защо спира сам famd, ще ми е ползезно да науча.
Виж за тази магийка с FAM не се бях сещал. Ники, често ли ти мре FAM ? Пробвай да ръчне?? /etc/init.d/fam (ако си с Debian), разбира се, за да тръгвам с опция “-d” и да му пренасочи?? изхода към някой файл. Ако даже и в debugging информацията няма нищо, значи трещи примерно със Segmentation fault. Тогава го пусни с ulimit ограничения разре??аващи писането на core файл и дебъгвай с GDB къде гърми. Още по-груб вариант, е да го пусне?? веднъж с “strace”, като изходът на strace го пренасочи?? към файл и анализира?? последните няколко стотин реда от файла след гърмежа :).
Не умира много често, по-скоро когато си поиска. Просто някой път умира след седмица, някой път след 1 ден. различно. Това с инрекативен режим го пробвах, но мисля че се получва забавяне , все пак има много връзки, а и масово клиентите са Outlook Express , и в най-натоварените монти достигат до 210-230 завки.
” imaplogin: 224 active connections”.
принуден съм да вдигна демоните за auth na 30 и IMAPD MAXDAEMONS=250 MAXPERIP=30, при по ниски стойности, започват предупреждения в системния лог ( не бях го забелязвал в по -ранни версии на courier imap . ) За това и не съм го държал прекалено много време в дебъг режим. проблема е разре??ен за сега доста грубо ;-), но за сега ефективно, с 1 Perl script ( разбирасе може и на shell, но по-лесно ми е на Perl) , който проверява ,дали е стартиран FAM, ако е спрял просто го пуска. Може да му добавя и да логва кога е спирал, но засега работи по описания начин и не съм забелязал да има оплакване. когато спре FAM , се наблюдава следнaта гр??ка:
“imaplogin: FAMNextEvent: Input/output error”,
“imaplogin: malloc: Input/output error”