Le 02/03/2014 05:43, David C. Rankin a écrit : > Slavek, > > One more issue with the tdeio_slaves failing to close is if kmail is left > open, the automatic checks for new mails done every 10 minutes or so, will cause > the mail server to begin rejecting connections after its anvil connection limit > is reached (due to the imap connections never being closed): > > This was from my mail server after I began getting imap connection rejects: > (all of those logins are from kmail that are stuck open) > > 953 ? Ss 0:29 /usr/sbin/dovecot > 1087 ? S 0:05 \_ dovecot/anvil > 1088 ? S 0:05 \_ dovecot/log > 15680 ? S 0:09 \_ dovecot/config > 31108 ? S 0:05 \_ dovecot/imap-login > 31112 ? S 0:11 \_ dovecot/imap > 1022 ? S 0:04 \_ dovecot/imap-login > 1026 ? S 0:06 \_ dovecot/imap > 20731 ? S 0:01 \_ dovecot/imap-login > 20737 ? S 0:02 \_ dovecot/imap > 21919 ? S 0:00 \_ dovecot/imap-login > 21921 ? S 0:01 \_ dovecot/imap > 23254 ? S 0:00 \_ dovecot/imap-login > 23255 ? S 0:01 \_ dovecot/imap > 25991 ? S 0:00 \_ dovecot/imap-login > 25993 ? S 0:01 \_ dovecot/imap > 32553 ? S 0:00 \_ dovecot/imap-login > 32557 ? S 0:01 \_ dovecot/imap > 15881 ? S 0:00 \_ dovecot/imap-login > 15883 ? S 0:00 \_ dovecot/imap > 16677 ? S 0:00 \_ dovecot/imap-login > 16678 ? S 0:00 \_ dovecot/imap > 19776 ? S 0:00 \_ dovecot/imap-login > 19780 ? S 0:00 \_ dovecot/imap > 23531 ? S 0:00 \_ dovecot/imap-login > 23535 ? S 0:00 \_ dovecot/imap > 23537 ? S 0:00 \_ dovecot/imap-login > 23538 ? S 0:00 \_ dovecot/imap > 1039 ? Ss 0:00 /usr/sbin/faxq > > > I'm making some progress on the investigation, but I'm not done yet. Unlike what I thought before, the problem is not in the TDElauncher. It's more likely around the TDEIO scheduler (tdelibs/tdeio/tdeio/scheduler.cpp). I've found out that the bug affect ioslaves having "remote files listing" feature (e.g. fish, ftp ...) but not the others (http ...). I believe the problem is inside the "kdirlister" class (tdelibs/tdeio/tdeio/kdirlister.cpp). When browsing a remote folder using fish://remote_host/remote_directory/ , the scheduler spawns a new tdeioslave to get the remote content, but this job never informs the scheduler that it has finished working. So the scheduler still believes the ioslave is busy, and does no reuse it. The iolave is stale forever. This is certainly a signal/slot issue. Probably one of the last commits here is the culprit: http://git.trinitydesktop.org/cgit/tdelibs/log/tdeio/tdeio/kdirlister.cpp When using the same protocol to get an exact file (no directory browsing), the problem does never occur. E.g: konqueror fish://remote_host/image1.jpg Francois