2 Mar
2014
2 Mar
'14
11:10 a.m.
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