trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2014

Re: [trinity-devel] Bug 1902 - tdeio_imap will exhaust available imap (anvil) if kmail open

From: "David C. Rankin" <drankinatty@...>
Date: Sun, 02 Mar 2014 15:59:29 -0600
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.

-- 
David C. Rankin, J.D.,P.E.

Attachments: