Sorry, I should've been more precise. I mean the former: *all* existing imapd processes stop functioning, i.e. they don't respond to commands anymore. I verified that at this point it is still possible to open other types of connections, e.g. POP. So master seems to be principally functional.Date: Fri, 31 Jan 2003 23:25:29 +0100 From: Sebastian Hagedorn <[EMAIL PROTECTED]> [...] When the number of impad processes reaches 200, no more processes are spawned, just as it should be. However, sometimes, not immediately, but definitely after a while *all* imapd processes will hang if we try to open more connections to port 143. This is 100% reproducible. If we kill one of the scripts and the number of processes goes down, all the imapd's get unstuck, but not until that happens.What do you mean by "hang"? Do they actually stop answering their current IMAP commands? Do they stop answering new connections when their current one goes away?
We straced master, which stayed in a select() call. I'll do the other things you recommend next week.I don't see any particular reason for (either) phenomenon making a quick gaze at the code. Probably grabbing the "strace" and a gdb backtrace of a "hung" imapd process would help figure out what they're waiting for. Might as well do master, too.
Thanks, Sebastian
--
Sebastian Hagedorn M.A. - RZKR-R1 (Flachbau), Zi. 18, Robert-Koch-Str. 10
Zentrum für angewandte Informatik - Universitätsweiter Service RRZK
Universität zu Köln / Cologne University - Tel. +49-221-478-5587
msg10791/pgp00000.pgp
Description: PGP signature
