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