Hi Can I resume the problem in : The server is blocked in a read, waiting for the client next command. (this is normal, 99% of the process are in this state). But the autologout procedure is not working! Then this means the SIGALRM that should awake the process never come or is not handled properly! I simple call to sleep() or signal() could disturb this. If this append only when using SSL, maybe the problem is here and the ALRM should bne reloaded somewhere. This is useless now, but files in $cyrus_imap/proc/* contains the user and the selected mailbox of all these processes this could be useful to know if this what not always the same user at the origin of the problem, because he was using an old outlook or something. Regards On Nov 16, 2007 5:33 PM, Ken Murchison <murch@xxxxxxxxxxxxxx> wrote: > > Sebastian Hagedorn wrote: > > --On 16. November 2007 09:37:42 -0600 Gary Mills <mills@xxxxxxxxxxxxxxx> > > wrote: > > > >>> Could you get a stack trace? If you have gdb you just call it with "gdb > >>> -p 19175". Then you can do "bt" at the prompt. I forget how to do it > >>> with Sun's debugger. > >> > >> Easy: > >> > >> # pstack 19175 > >> 19175: pop3d -s > >> fef9f810 read (0, 2316f0, 5) > >> fee1d2d0 read (0, 2316f0, 5, 0, 0, 0) + 5c > >> ff06bb38 sock_read (1f0860, 2316f0, 5, 5, 0, 0) + 24 > >> ff068af0 BIO_read (1f0860, 2316f0, 5, fef98b84, 0, 0) + 110 > >> ff278488 ssl3_read_n (212798, 5, 8805, 0, 0, 203958) + 174 > >> ff2785fc ssl3_get_record (204ce0, 8000, 8400, 4400, f1, f0) + d0 > >> ff279424 ssl3_read_bytes (212798, 1000, 2000, 4, 0, ffbfe731) + 228 > >> ff27a99c ssl3_get_message (ff2a259c, 2070a0, 0, ffffffff, 19000, > >> ffbfe7a0) + d0 ff27042c ssl3_accept (2150, 2160, 2180, 21e0, 2110, 2122) > >> + 904 ff27bd2c ssl23_get_client_hello (2316fb, 6c, 6c, 4, fffffe79, 0) > >> + 828 ff27b4b4 ssl23_accept (4000, 2000, 0, 0, 0, 0) + 2a4 > >> 00032d00 tls_start_servertls (0, 1, ffbfee24, ffbfee20, 1849a8, ff00) > >> + 198 0002c504 cmd_starttls (1, 1fd8b8, 0, 0, 0, 0) + 184 > >> 0002a638 service_main (2, 192198, ffbffce0, 1aec4, 3508c, 1) + 488 > >> 00035250 main (2, ffbffcd4, ffbffce0, 17c400, 0, 0) + e18 > >> 00029298 _start (0, 0, 0, 0, 0, 0) + 108 > > > > Thanks, that looks like progress! That stack trace looks similar enough > > to the one I'm seeing that I could imagine that it is what I *should* be > > seeing if the stack weren't garbled. Of course that's only speculation. > > > > Ken, is it possible that the call to SSL_accept() in > > tls_start_servertls() blocks when the client goes away? That could > > explain everything .... > > Yes. Gary's problem might be very similar to yours, depending on what I > see from the patch that I just sent you. > > -- > Kenneth Murchison > Systems Programmer > Project Cyrus Developer/Maintainer > Carnegie Mellon University > ---- > > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ > Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html > -- Alain Spineux aspineux gmail com May the sources be with you ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
