>>> If that is called before getsockname, it means it is in bdbobj_open, >>> right? Are processes starving because of some locking mechanism? >> >> I think at this point the db (smtpaccess.dat) is already open, the hang >> is >> when the process makes queries. >> >> As I could trace: >> . tcpd/tcpd.c: >> function "accepted" calls "allowaccess" > > I saw "sox_getsockname" is called before "allowaccess", thence my > guess that it was in the former call. However, yes, there is a further > call to "sox_getsockname" in "run", after "allowaccess" in the child.
The call for "sox_getsockname" before "allowaccess" only happens if "accesslocal" is set. And its not on my system. >> function "allowaccess" calls "doallowaccess" >> function "doallowaccess" calls "chkaccess" >> . tcpd/tcpdaccess.c: >> function "chkacess" calls "dbobj_fetch" > > Mind that you have twice #define dbobj_fetch in dbobj.h > >> . bdbobj/bdbobj.c: >> function "dbobj_fetch" calls "doquery" >> ** The process get locked on a infinity loop at "doquery" function >> ( >> for (;;) ) >> function "doquery" calls "dofetch" >> function "dofetch" calls "(*obj->dbf->get)" >> From here I could not trace anymore, but I guess it is a call for the >> gdbm library. > > The _db-4_ library, actually. dbf->get gets mapped to an interface > function in the call to db_create (e.g. "__db_get_pp"). > > However, your further posts imply you are using gdbm, thus you should > check gdbmobj/gdbmobj.c: function "gdbmobj_fetch". Or have you been > switching from bdb to gdbm during the weekend? I had always use gdbm. I do not know yet how to switch to bdb, but if my fix on gdbm do not work I will try to move. >> The fetch is never returning successfully. So the function get locked >> on >> the loop. > > I don't understand those repeated read() calls returning 0. It should > mean end of file, thus there should be no point in insisting. For > EINTR, read should return a negative number, and strace should report > that. (My strace looks quite similar to your "normal operation" one, > however I have pread rather than read, and no lseek, with bdb4.4) I think this is the bug on Debian gdbm package. The patch they made to the official release may ignore EINTR. I will test my package for more a few days and if there is no more hangs I will repot to Debian bugtrack. Thanks for pointing me the way. Marcus ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
