On 03/28/2011 10:20 AM, Karoly Czovek wrote:
Let me wait for the next errors, switched back accesslog
pkg info:


Name       : 389-ds-base
Arch       : i386
Version    : 1.2.7.5
Release    : 1.el5
Size       : 5.4 M
Repo       : installed
Summary    : 389 Directory Server (base)
Ok.  I think this is https://bugzilla.redhat.com/show_bug.cgi?id=668619 which has been fixed in 389-ds-base-1.2.8.a2 - 389-ds-base-1.2.8.rc2 is now in testing.  You could see if you can reproduce the problem in a non-production environment
yum install --enablerepo=epel-testing 389-ds-base



On Mar 28, 2011, at 6:11 PM, Rich Megginson wrote:

On 03/28/2011 10:09 AM, Karoly Czovek wrote:
lance:~# /usr/bin/ldapsearch  -x -LLL uid=karoly.czovek
ldap_result: Can't contact LDAP server (-1)
lance:~# echo $?
254


[here i restarted 389ds on the ldap server]

lance:~# /usr/bin/ldapsearch  -x -LLL uid=karoly.czovek
dn: uid=karoly.czovek,ou=People,dc=moveone,dc=info
gidNumber: 1010
mailAccountStatus: Active
mailUserHome: /home/vmail/karoly.czovek
[...]
Ok.  Thanks.
What version of 389-ds-base are you using?  What do you see in the access log from around the time of a failed client connection attempt, from ldapsearch or from some other client?




On Mar 28, 2011, at 5:18 PM, Rich Megginson wrote:

On 03/28/2011 09:09 AM, Karoly Czovek wrote:
i can reproduce, but the server is in production.
if the clients got this error then i also unable to connect with ldapsearch.
Ok, what is the error code?

just now appeared, i have full verbose trace logs, but nothin intrestring,
but a ton from theese 

28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023ffa8, handle=3
[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fed8, handle=3
[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fe08, handle=3
[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fd38, handle=3
[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fc68, handle=3
What error log level are you using?  These messages are ok.  The errors log messages are going to be unhelpful at best, and misleading at worst, if you use specific log levels like CONN and TRACE, without looking at the code.


for the period. increased the files and restarted the srv, let me see what happens...
any other idea, advice what settings are  needed for large amount of queries from 389ds  ldap?
I still don't have enough information from you to make that determination.  What version of 389-ds-base are you using?  What do you see in the access log from around the time of a failed client connection attempt, from ldapsearch or from some other client?



On Mar 28, 2011, at 4:42 PM, Rich Megginson wrote:

On 03/28/2011 08:29 AM, Karoly Czovek wrote:
the server is 32bit, the exact client error message is cannot connect to the server.
But what is the error code?  80?  81?  91?  If you can reproduce with ldapsearch, in the shell, $? should hold the error code
(even ldapsearch cant). let me check the logs once appearing the errors again,
now disabled the restart cronjob.




On Mar 28, 2011, at 4:16 PM, Rich Megginson wrote:

On 03/28/2011 03:45 AM, Karoly Czovek wrote:
Hi All, 


Is there any reason, workaround for the 389DS about high-rate queries?
Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam
What version of 389-ds-base?  32-bit or 64-bit?

After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure.
What are the exact client error codes/messages?  Any errors in the dirsrv errors log?  Can you post excerpts of the dirsrv access log from around the time of the client errors?
The 389DS has 2 cores with 2GB of ram, related settigns are the following:


Karoly CZOVEK
Global Systems Administrator
MoveOne IT Department

Eastern Europe - Balkans - CIS&  Central Asia - Middle East&  Africa -
Asia Pacific
phone: +36 1 266 0181 - ext.6710
mobile: +36 70 708 9953
skype: mo_karoly.czovek
email: karoly.czovek@moveoneinc.com
web: http://www.moveoneinc.com

-- 
Karoly CZOVEK
Global Systems Administrator
MoveOne IT Department

Eastern Europe - Balkans - CIS&  Central Asia - Middle East&  Africa -
Asia Pacific
phone: +36 1 266 0181 - ext.6710
mobile: +36 70 708 9953
skype: mo_karoly.czovek
email: karoly.czovek@moveoneinc.com
web: http://www.moveoneinc.com



-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users


-- 
Karoly CZOVEK
Global Systems Administrator
MoveOne IT Department

Eastern Europe - Balkans - CIS&  Central Asia - Middle East&  Africa -
Asia Pacific
phone: +36 1 266 0181 - ext.6710
mobile: +36 70 708 9953
skype: mo_karoly.czovek
email: karoly.czovek@moveoneinc.com
web: http://www.moveoneinc.com



-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users


-- 
Karoly CZOVEK
Global Systems Administrator
MoveOne IT Department

Eastern Europe - Balkans - CIS&  Central Asia - Middle East&  Africa -
Asia Pacific
phone: +36 1 266 0181 - ext.6710
mobile: +36 70 708 9953
skype: mo_karoly.czovek
email: karoly.czovek@moveoneinc.com
web: http://www.moveoneinc.com



-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users


-- 
Karoly CZOVEK
Global Systems Administrator
MoveOne IT Department

Eastern Europe - Balkans - CIS&  Central Asia - Middle East&  Africa -
Asia Pacific
phone: +36 1 266 0181 - ext.6710
mobile: +36 70 708 9953
skype: mo_karoly.czovek
email: karoly.czovek@moveoneinc.com
web: http://www.moveoneinc.com



-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users