On 03/02/2014 05:10 AM, François Andriot wrote:
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).
Interesting. Any progress is good progress. One concern I had -- that not somehow placing preprocessor conditionals around the tdm/backend/dm.h (line 40) '#define WITH_CONSOLE_KIT' was causing an incorrect declaration of StartClient() at dm.h line 487:
#ifdef WITH_CONSOLE_KIT int StartClient( const char *ck_session_cookie ); #else int StartClient( void ); #endif
I added fprintf(stderr,....) statements inside each of the WITH_CONSOLE_KIT statements to try and catch whether the WITH_CONSOLE_KIT statements were being utilized. So far, I haven't seen any pop up in the logs. (I've attached the patch with the fprintfs if you are curious).
I have also built with an explicit register of the the greater with pam as suggested by freedesktop.org:
#ifdef WITH_SYSTEMD if ((pretc = pam_misc_setenv( pamh, XDG_SESSION_CLASS, "greeter", 0 )) !=PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } if ((pretc = pam_misc_setenv( pamh, XDG_SEAT, "seat0", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } if ((pretc = pam_misc_setenv( pamh, XDG_VTNR, "7", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; }
The build it complete, but I have not yet had time to test. I'll report back if that makes any difference with logind.
I've found out that the bug affect ioslaves having "remote files listing" feature (e.g. fish, ftp ...) but not the others (http ...).
I don't think this is right. I have many, many abandoned tdeio_http and tdeio_file processes left running on my system. I think it effects ALL tdeio.
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
Was this another renaming patch to blame? I'll look.
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
Thank you for your help Francios. I look forward to fixing the tdeio issue and then fixing the logind/loginctl problem so I can actually have sound and use usb drives again.